4 ms·

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

barbazoo 5y ago
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.
- afidrya 5y ago
  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.
- sodapopcan 5y ago
  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).
mportela 5y ago
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/ https://github.blog/2016-04-01-squash-your-commits/
- julenx 5y ago
  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)
  - avgcorrection 5y ago
    This is exactly what happens in practice.
- avgcorrection 5y ago
  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.
mhitza 5y ago
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.
- altonen 5y ago
  If you use git-rerere you don't have to fix the same conflicts over and over again
- unicornmama 5y ago
  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.
bastardoperator 5y ago
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.

afidrya 5y ago
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.
sodapopcan 5y ago
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).

mportela 5y ago

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/ https://github.blog/2016-04-01-squash-your-commits/

julenx 5y ago
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)
- avgcorrection 5y ago
  This is exactly what happens in practice.
avgcorrection 5y ago
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.

mhitza 5y ago

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.

altonen 5y ago
If you use git-rerere you don't have to fix the same conflicts over and over again
unicornmama 5y ago
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.

bastardoperator 5y ago

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