I originally posted this on My Blog.
Take 3 commits: abc, def, ghi
And let's suppose you have two git branches: master and production.
Production's history currently looks like this:
Master is two commits ahead:
abc -> def -> ghi
You open a Pull Request to get def and ghi into production.
You have a few options for how to merge the Pull Request. All of these methods serve the purpose of getting the code from def and ghi into the production branch - the main differences center around the commit histories of the two branches afterwards.
I very rarely use this option in my work. As I understand it, it creates a sepearate commit, let's call it jkl, that describes the merging of ghi into production.
Squash merge combines def and ghi into a new commit, let's call it mno, and then merges that.
If you squash merge your PR, you'd end up with:
abc -> def -> ghi
abc -> mno
The commit histories for master and production, even though they have the same code, no longer have the same commits in them.
Rebase merge replays all of the new commits (def and ghi) onto production:
abc abc -> def abc -> def -> ghi
At the end, master and production would look exactly the same.
If I can help it, I prefer Rebase merge. It avoids creating new commits, so it often results in a cleaner commit history between branches. Sometimes I use squash merge if my branch has a bunch of commits like:
ahioh: feat: do something inkcl: lint error apsdq: fix test apsap: please work pwowq: Finally working
That way, the commit history doesn't show my stream of consciousness as I fight with linters, continuous integration, and test suites.
As I mentioned, I don't often use merge commits - I'm sure they have a use case, but I don't find them helpful to me a majority of the time.