Git. To rebase or not to rebase?

This is the question. Git has been around from some time now and offers lots of functionality in comparison with SVN. If you’re not using git by now, you are a dinosaur. But this is not about git vs SVN. It’s about merging vs rebasing. When to use one or the other. There is a thing  called The Golden Rule of Rebasing.

“The golden rule of git rebase is to never use it on public branches.”

Obviously this makes sense. But we need to be careful to each word.  The question that appears here is: “What about getting latest updates from origin branch?” After all the origin branch is a public branch. But we are not rebasing on it. We are rebasing on our private branch, which does not break the rule. Now here there comes the difference of opinions.

git pull vs git pull –rebase

Behind the scenes both of them will do a git fetch origin, but after that one does merge and the other rebase. The first will create a merge commit, while the second will do put your changes on top of the others. The first will create an extra merge commit (but maybe we don’t really care about the history), while the second will create a clean history (but can rewrite history which can be dangerous if not used properly). Example time.

Git pull (develop branch)

Git merge (master branch)

Hard to read, but if you are using feature branch strategy you don’t really care. An extra merge commit will appear.

Git pull –rebase (develop branch)

Git merge (master branch)

As you can see the history it’s clean and trackable.  Less commits, easy to fix things and easy to read the reflog. On the other hand, you have the power to rewrite(and possibly break things) if you don’t know what are you are doing.

I was always guided by the next rule of thumb:

“Use rebase for getting the latest updates for your branch from origin and use merge when you want to put code from one branch to another”

But, you could have an addition to this rule which can state:

“You can rebase private branches as long they don’t have a public mirror”. But you should be comfortable with git and must to keep everything clean (squash commits). When this can be applied? Well for example you want to try something new for your project, upgrade technologies as seamless as possible. Of course you will have more commits on this “upgrade” branch, but you don’t want it public. Instead of merge, you could squash the commits into one and rebase it on your feature branch with the name “Upgraded this..that”. If for some reason at some point you want to revert this it will be straightforward; there is only one commit. But merge will also do the trick. Depends on your flavor.