I'm still somewhat new to Git so now and again I come up with a question that's so obvious to other developers that it doesn't seem to be answered anywhere. One such question is "when should a merge be squashed?"

Squashing a merge means taking all the commits that would normally be replayed individually on your target branch and replaying them as one large commit.

Well, as far as I can tell, here's the answer: squashing a merge is appropriate when all the commits in the merge deal with one topic.

As an example, consider having a branch that deals with the performance of one particular method. Each time you increase the performance you commit your changes. After a few days of this you have several commits in your branch and a lovely fast implementation that you want to merge back to the master branch. The merge from your branch to master should be a squashed commit and your commit message should explain what you did to speed up the implementation.

git merge --squash speed-up-the-method

An unsquashed commit could be more appropriate if you're merging from a development branch since in this case the branch should be composed of a nicely formatted series of commits based on topic relevant to the development branch.

git merge dev/v1.2.3

When doing an unsquashed commit your repository will use the original commit messages.

written by
Craig
published
2008-12-18
Disagree? Found a typo? Got a question?
If you'd like to have a conversation about this post, email craig@barkingiguana.com. I don't bite.
You can verify that I've written this post by following the verification instructions:
curl -LO http://barkingiguana.com/2008/12/18/when-should-a-merge-be-squashed.html.orig
curl -LO http://barkingiguana.com/2008/12/18/when-should-a-merge-be-squashed.html.orig.asc
gpg --verify when-should-a-merge-be-squashed.html.orig{.asc,}