All About that Rebase

Squashing some common Git merge patterns

Background

Take 3 commits: abc, def, ghi And let's suppose you have two git branches: main and production.

Production's history currently looks like this:

abc

Main is two commits ahead:

abc -> def -> ghi

You open a Pull Request to get def and ghi into production.

Merge types

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.

Merge Commit

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

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:

main:

abc -> def -> ghi

production:

abc -> mno

The commit histories for main and production, even though they have the same code, no longer have the same commits in them.

Rebase Merge

Rebase merge replays all of the new commits (def and ghi) onto production:

abc

abc -> def

abc -> def -> ghi

At the end, main and production would look exactly the same.

Conclusion

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.