1120
Rebase Supremacy (programming.dev)
submitted 2 years ago by to c/programmer_humor@programming.dev
235 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 16 points 2 years ago (9 children)

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.

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 1 point 2 years ago (8 children)

    Squash and rebase or squash or rebase?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 6 points 2 years ago (7 children)

    ..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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 1 point 2 years ago (5 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 3 points 2 years ago (4 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 2 years ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 2 years ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 2 years 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 2 years 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.

  • permalink
  • fedilink
  • source
  • parent