I hate squash.

Not that kind of squash.

I hate GitHub’s “squash merge” feature.

And I hate the equivalent from GitLab or any other VCS interface.

Of course, if that’s your preference, I’m not here to tell you you’re wrong (even though you are! 😂)

But I am here to tell you why I hate it. Maybe you’ll agree. Maybe you won’t. In either case, I hope whatever opinion you walk away with will be more informed.

First, what does this option even do?

Let’s imagine you have a pull request with three commits:

• 00509ca7 Add amazing feature
• c9cb60b2 ???
• ed5084dc Profit!

When you merge this pull request using the “Squash merging” feature, you’ll end up with a single commit:

• b2798a04 Add amazing feature

Ostensibly this makes the git history cleaner. In some cases, this can be true. If you have PRs that look like this:

• 00509ca7 Add amazing feature
• 60b725f1 typo
• 0c9c85c7 typo
• 0d97880d bug fix
• fe8191b3 spelling
• c9cb60b2 ???
• 3b5d5c37 argh
• 12955042 fix
• 21231617 i’m stupid
• 3ccf37be typo
• ed5084dc Profit!

Then squashing on merge probably is a benefit.

But you know what would be even better? NOT DOING THAT

Make sure every commit message is meaningful, and that every comit stands on its own. If they don’t, by all means do manual/interactive squashing of relevant commits. But squash-merging is just adding inuslt to injury, in my opinion.

Let’s assume you and your team have therefore learned to write meaningful commit messages (or are at least working on learning to). This leaves two possible scenarios:

1. Our PRs are long, with multiple commits. Merging them is actively harmful, because it obscures history. One project I was recently working on with squash-merging merged a 2-month feature branch in a single commit. UGH. It’s literally impossible now to see how that feature evolved, and how decisions were made. Of course long PRs are an anti-pattern in their own right, which leads us to the second possibility…

2. Our PRs are short. Possibly only a single commit in the first place. Because the team is good at working in small slices, we have very small PRs, and we merge them quickly. So in this case, squash-mergning is either an actual no-op (squashing a single commit results in a single commit) or very nearly so (squashing two commits into one doesn’t hurt history all that much).

So this is why I come down on hating squash-merging: If the team is observing good commit/PR hygiene, with micro-commits and micro-PRs, squashing is unnecessary. If they aren’t, squashing obscures history, and enables, if not outright encourages, bad practices (such as commits with the description “bug fix”).

If your git history is full of noise like “typo”, it’s better to solve that problem precisely, and write good commit messages. “Merge squashing” is too blunt of an instrument.

What do you think?

Still prefer squash merging? I’d love to hear why!