Member-only story
Why I Prefer Regular Merge Commits Over Squash Commits
I used to think squash commits were so cool, and then I had to use them all day, every day. Here’s why you should avoid squash
“Wow, that’s so cool!”
I’ll always remember seeing my first squash commit.
When I first joined a large engineering organization with more than 200 members, the squash commits were the first thing I noticed.
To me, the consistent use of squash commits across the company screamed “professionalism” and “we know what we’re doing here!”
It took me about a month to realize that I really, really didn’t like squash commits, and I started longing for good, old-fashioned merge commits.
Comparing Squash vs. Merge Git Commits
As a refresher, the difference between a “squash commit” and a “merge commit” is that a regular “merge” includes all of the Git commits in the history of the target branch, while “squash” flattens them to one commit.
Confusingly, “squash” isn’t its own command. Instead, you can choose “squash and merge” or “squash and rebase” as an option when you’re running the git merge or git rebase commands, respectively.
By default, a pull request (PR) will be a merge commit, so after the PR is merged then the entire history of the working branch will be merged in, plus an additional commit (“Merge pull request #21 from branch…”).
On the other hand, you can set your repository to “squash and merge” by default, meaning merged PRs will result in only a single commit each, instead of bringing over all the commits from the working branch.
Why Would Anyone Use Squash Commits?
The benefit of squash commits is that you keep a “clean” Git commit history. Since we developers are famously… let’s say “precise”… then a tidy commit history sounds absolutely fantastic. It’s not.
You can see why I was impressed by the professionalism — the entire engineering organization was so dedicated to having a clean commit history that they had mandated “squash and merge” as the default!
