• jjjalljs@ttrpg.network
    link
    fedilink
    arrow-up
    16
    ·
    7 months ago

    I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.

    All the garbage “spelled thing wrong” and “ran formatter” commits go away. Main is clean and linear.

      • jjjalljs@ttrpg.network
        link
        fedilink
        arrow-up
        6
        ·
        7 months ago

        …and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.

        You then rebase so you have a nice linear history with no weird merge commits hanging around.

        • GissaMittJobb@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up

          The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.

          Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.

        • cobra89@beehaw.org
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.

          • jjjalljs@ttrpg.network
            link
            fedilink
            arrow-up
            3
            ·
            7 months ago

            There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.

            Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch

            Rebase takes your commit(s) and sticks them on the end.

            Merge does something else I don’t understand as well, and makes a merge commit.

            Also there was an earthquake in NYC when I was writing this. We may have angered the gods.

            • cobra89@beehaw.org
              link
              fedilink
              arrow-up
              1
              ·
              7 months ago

              Lmao I’m in the NYC area and my whole house shook. I’m right there with you. Thanks for the explanation!

            • Atemu@lemmy.ml
              link
              fedilink
              arrow-up
              1
              arrow-down
              1
              ·
              7 months ago

              You should IMO always do this when putting your work on a shared branch

              No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.

              Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
              If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.

              Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.

              • jjjalljs@ttrpg.network
                link
                fedilink
                arrow-up
                2
                ·
                7 months ago

                I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.

                Do you?

                Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.

                • Atemu@lemmy.ml
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 months ago

                  Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.