It’s an endless debate. Like spaces vs. tabs. emacs vs. vim. Windows vs. Mac. Before joining Automattic, creating a merge commit was the only way I would close PRs. That would get the job done. Perhaps the other merge options were for advanced use cases, I thought.
Now that I’ve been using the “squash & merge” option extensively for a while, I can better appreciate this option. I think no option is better than the other. Both have their pros and cons.
If you are into carefully crafting all your commit messages—which everybody should be doing anyway—you know the value of a merge commit. It appends all commits of a branch to the target (main) branch. That way, your commit messages are closer to the code they describe. So, each line of code reveals a more precise history with git blame.
A squashed commit collates all code changes into a single commit. As a result, commit messages also get consolidated. This can be annoying for some as this often results in a very large commit message.
Sure, short messages that describe a line are more useful than walls of text that result from a squash. On the bright side, knowing that all my commit messages would be compacted into one commit allows me to compose shorter, context-free messages. So, rather than writing “Add tests for XYZ functionality” I can just write “Add tests” knowing that the title of my PR would become the first line of the squashed commit which would set the context.
So one definite benefit of using squash & merge is the time you get back from thinking too much about the right commit message where the first line may only be 50 chars long and should hopefully tell the whole story.
If you are into the art of creative writing, you’ll find using the merge commit option as a good practice playground. The rest of us can stick to squashing.