Zach Olivare - 2022 Nov 22
Which merge strategy should your team use for PRs?
...is no. It is almost always better to merge PRs via a merge commit. Squashing has a lot of downsides and few benefits. But for teams that don't want to to take the time to ensure that all their members are comfortable using Git, squashing is better than the alternative of merging with reckless abandon.
Squashing commits in Git just means combining multiple commits into a single commit. This post is talking about a squashing merge strategy, which is a way of closing a Pull Request (PR) by combining all the commits in that PR into a single commit, and then plopping that single commit right on top of
main (or whatever branch you're merging into).
A part of the choice of merge strategy is where you (and your team) fall on the Simplicity vs Usefulness spectrum. Are you willing to sacrifice having your Git history as a tool in your bug-fixing-toolbox in order to have a simpler workflow?
Are you (and the other members of your team) willing to take the time to learn how to use your version control software of choice (Git) to get the most out of it? Or is ignorance bliss?
When comparing squashing to a rebase-and-merge strategy, squashing is definitely a simpler workflow. And everyone can agree that squashing is better than the unusable merge nightmare that you get if you don't squash PRs and no one cares about their Git commits.
But squashing has trade offs that you don't have to make if you (and your team) can use Git for more than
Almost everyone agrees that Git commits should be atomic; and squashing is the anthesis of atomic commits. Sometimes large PRs are unavoidable and squashing them creates horribly dense commits.
Clearly, squashing your PRs has a lot of downsides. But I think it's fair to say that there are two benefits.
In my experience, a lot of developers are kind of afraid of Git. They look at it like a black box. They're afraid that if they do the wrong thing, they're going to mess things up for their whole team. When the reality is quite the opposite! Until you run
git push, nothing you do in your terminal can have any effect on your teammates.
If you squash all your PRs, then the commits you make inside of that PR don't matter. You can have 9
:derp: commits (more on commit messages here) and you don't have to worry about your commits being atomic or separating your feature work from your refactoring, because all your commits are going to be essentially deleted when you merge your PR.
If you set your repo's default merge strategy to be "squash", then the members of your team who aren't paying attention to their commits will just leave the default and squash all their PRs.
Still leaving the option to create a merge commit though allows the developers who have taken the time to craft a useful commit history to be able to preserve that history in the
If you have dozens of developers contributing to the same repo, or if you don't have confidence that your team could learn how to use the git rebase command, then squashing PRs might be your best bet.
If on the other hand your team wants to take a little time and learn how to use the most popular version control system in the world (Git), then each team member and your repository itself will be better off for it in the long run.