Hacker News Reader

Comment by unicornmama | Hacker News Reader

10+ years and I still don’t understand why developers and orgs think it’s necessary to squash and rebase.

AFAIK it's usually to keep the git history clean but doing it manually is so painful. In my company, we enabled GitHub's "Squash and Merge" option (1) so we have the best of both worlds: a clean history and an 1-click squash process.

(1) https://github.blog/2016-04-01-squash-your-commits/

With GitHub's squash + merge, clean history still depends on the person doing the merge, because when clicking the squash + merge button, GitHub places all commit messages in one large chunk of text, which devs are able to edit before confirming the merge, but it takes some discipline to do so.

In my experience, devs rarely pay attention to this, so commit messages end up as a big list of:

  * Ticket-1234 feature
  * fix
  * cleanups
  * fix
  * another fix
  * now the real fix

Which I wouldn't qualify as a contributor to a "clean" history. It'd be great if GitHub's UX around crafting the commit messages would be more considerate and foster more meaningful commit messages.

(edit: formatting)

This is exactly what happens in practice.

There’s nothing particularily clean about a multi-week pull request with 50+ commits getting squashed with all the commit messages concatenated together as bullet points. I’ve tried to go back to commits/issues like that and it’s hard to understand what one section of the commit message corresponds to in the diff.

There’s no way to automate version control.

I've seen two main arguments to that workflow.

One argument, and which I hear often, is that they want to keep the git history clean.

The other argument is that keeping things rebased & squashed allows you to do reverts easily.

I personally don't mind the merge commits cluttering the history, and especially when working on a longer lived branch I will always prefer merging-in changes rather than constantly rebasing and fixing same conflicts ad nauseam.

If you use git-rerere you don't have to fix the same conflicts over and over again

You can do reverts just as easy with merge commits.

git revert -m 1 $commit

You can also visualize a clean history with merge commits.

git log —-first-parent

The only argument I’ve heard that holds weight is that GitHub’s UI squashes the merge commit history into a linear view.

Is it that you truly do not understand? Or don't agree with common reasoning behind squash/rebase?

For me it's a combination of commiting often and keeping the history readable. To achieve both I have to a) squash commits before merging otherwise I end up with dozens of intermediate commits and b) rebase, otherwise I end up with a history that looks like the Tokyo subway system.

Downside of squashing as opposed to making a merge commit (without fast forward) or merging by rebasing, however, is losing granularity. Later it'll be hard to roll back a small part of PR while keeping rest of the changes.

Also it'll be harder to go back and review changes when troubleshooting issues because formatting changes were squashed together with business logic changes. With merges at least there are still original commits available, and it'll be possible to either rollback everything or a single commit.

I could be wrong, I feel like OP is talking about the workflow where the entire branch is squashed before it is integrated into the main branch, not squashing intermediary commits into more logical ones (which is what I think you are talking about).

Reply on news.ycombinator.com