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:
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.