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
Diff-n-patch
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.
Kparal's Fedora Blog 
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 😉
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!
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!
😀