• Nate Cox@programming.dev
      link
      fedilink
      English
      arrow-up
      22
      ·
      7 months ago

      I remember learning about how to use this back in the day and what a game changer it was for my workflow.

      Today I like to do all of the commits as I’m working. Maybe dozens or more as I chug along, marking off waypoints rather than logging actual changes. When I’m done a quick interactive rebase cleans up the history to meaningful commits quite nicely.

      The fun part is that I will work with people sometimes who both swear that “rewriting history” is evil and should never be done, but also tell me how useful my commit logs are and want to know how I take such good notes as I go.

      • swordsmanluke@programming.dev
        link
        fedilink
        arrow-up
        21
        ·
        7 months ago

        Argh. I hate that argument.

        Yes - “Rewriting history” is a Bad Thing - but o argue that’s only on ‘main’ (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.

        If you rewrite main’s history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don’t be that guy.

        Before you push though… rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.

        • review is easier since concerns aren’t mixed
        • If a commit needs to be reverted it limits the collateral damage
        • history is easier to follow because the commits tell a story

        I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.

        Anyway. Good on you; Keep the faith; etc etc. :)

        • thesmokingman@programming.dev
          link
          fedilink
          arrow-up
          5
          ·
          7 months ago

          The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.

      • magic_lobster_party@kbin.run
        link
        fedilink
        arrow-up
        6
        arrow-down
        3
        ·
        edit-2
        7 months ago

        At my company we just use a squash policy in gitlab. Every merge request becomes a single commit to the main branch. Super easy to read the commit log because all commits are descriptive instead of a bunch of “fix MR comments” or “fix pipeline errors”.

        Another advice: git reset [commit-id] followed with a git commit -a is a quick way to squash all your commits.

        • bort@sopuli.xyz
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          Another advice …quick way to squash all your commits

          in your IDE select the commits you want to squash. Then rightclick. Then “squash”. All done.

            • bort@sopuli.xyz
              link
              fedilink
              arrow-up
              3
              ·
              7 months ago

              I use like 3 of the git-feature from intellij (out of 100 or so). But these 3 features save me a lot of time.

              (the other 2 being the 3-way-merge-view and the commit-view where I can select changes for staging)

      • sping@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        edit-2
        7 months ago

        Even better, master creating fixup and squash commits and maintain logical commits as you work with git rebase -i --autosquash

    • dejected_warp_core@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      7 months ago

      This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling git log, but that’s usually for commits outside of what I’m trying to merge.

      Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.