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

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.


Flattr this

Git Tip of the Day – check for whitespace errors in diff

When creating and applying patches, git often complains about whitespace errors. Whitespace changes are generally not desirable, because they make the diff longer and diverts your focus from (very probably) more important changes. From this reason git tries to provide warnings for whitespace changes that might have not been needed. This includes trailing whitespace, spaces before tabs in indentation and empty newlines at the end of a file.

If you execute

$ git diff

and have colored output enabled, git marks these changes with light red background.

But if you don’t have colored output enabled, or maybe your patch is too long and you don’t want to scroll through it, there’s an easier way to check for whitespace errors. Just execute

$ git diff --check

You can then receive output like this:

$ git diff --check
README:7: trailing whitespace.
+or ask in #fedora-qa on the freenode IRC network.  
README:13: space before tab in indent.
+       'autoqa' is the main binary that kicks off tests
TODO:14: new blank line at EOF.

And now you know what to fix.

If you’re working on a patch for some project and you’re about to send it, use this simple command to check for whitespace errors. It will then save a little work for everyone who’s going to read the diff (or the commit log).

Happy gitting!


Flattr this