Git Tip of the Day – squashing merges

You certainly develop your new features in so-called feature branches – i.e. other branches than master. What’s your approach when your new feature is complete and you want to put that code into the master branch?

Up till now, I used one of these two methods:

Merge the branches

If my feature branch, let’s call it newstuff, contains just a single or very few commits and all of them being high-quality (well separated code changes, descriptive commit messages), I would simply merge master and newstuff.

$ git checkout master
$ git merge newstuff


If my newstuff branch contains loads of commits, or they are of poor-quality (my favorite “WIP” strings as commit messages, etc), I would create one big patch against master and then apply it there. Therefore I wouldn’t pollute master with low-quality changes.

$ git checkout newstuff
$ git rebase master  # or 'git merge master'
$ git checkout master
$ git diff --binary master newstuff > patch
$ git apply patch
$ rm patch

This is somewhat tedious approach.

But today is my lucky day. I found a way to do the second approach much easier:

Squash merging

I decided to the the second approach (diff-n-patch) but I want something faster, without the intermediate step of creating a patch file. That’s exactly what squash merging can do:

$ git checkout master
$ git merge --squash newstuff

This has several advantages. First, it’s simpler (yay!). And second, you don’t necessarily need to make sure that newstuff is on top of master first (by merging or rebasing), because this approach uses git intelligent merging algorithm to detect and resolve conflicts.

The net effect is that you’ve just put your new code to master with just a single commit.

Flattr this

4 thoughts on “Git Tip of the Day – squashing merges

  1. What about the third method? “rebase-n-merge”

    I think that this should be mentioned too.
    It might be more work, but sometimes the branch contains too many changes to be a single logical, bisectable commit, but also it got lot’s of “WIP” commits.

    Of course you have to be extra careful not to break other peoples work, which might be based on that branch.

    But normally people should base on master and not short lived feature branches which come and go all the time.

    Also, with git rebase -i, the process gets really simple.

    But otherwise, yes git merge –squash is really nice 😉

    1. Yes, you are correct, sometimes rebasing into several logical commits is the best approach. I’ll talk about that in some later git tip 🙂 Thanks!

  2. Thanks a lot for this tip!

    I’m just learning git and merging a branch with a single commit was just one of the things I was trying to achieve!


Leave a Reply (Markdown syntax supported)

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s