Squash and merge is one of the ways to land a pull request. Instead of carrying every commit from the branch into main, Git combines them into a single new commit with one message. The branch might have had forty commits. Main gets one.
On GitHub it is one of three options on the merge button, next to “Create a merge commit” and “Rebase and merge.” Repository admins can allow or disable each method in the repository settings. GitLab offers the same idea as a “Squash commits” option on a merge request. On the command line, git merge --squash stages the combined changes for you to commit yourself.
The appeal is a readable history. Each commit on main maps to one reviewed change, which makes git log, git blame and git bisect easier to work with. It also means nobody has to see the commits called “wip” and “fix typo again.”
The trade-off is detail. The individual steps inside the branch are no longer in main’s history, and if the branch was long-lived or shared, the squashed commit can be large and harder to revert in parts. If the steps matter, clean them up with an interactive rebase and use a merge commit or rebase and merge instead.
Two practical tips. Edit the squash commit message before you confirm it, because the default is often a pasted list of every commit title. And delete the branch afterward: since its commits never landed on main as-is, Git will not consider it merged.
The shirt says “SQUASH & MERGE.” in one line, which is the point of the feature.
In the wild
Squash and merge please. The branch history is mostly me arguing with the linter.
