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
[–] 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