To rebase, or not to rebase - for me its not really a question. I generally prefer a clean, linear commit history. Why? Because merge bubbles make history confusing, noisy, and can break git bisect.

Don’t believe me? Check out the pretty log to the right. See all those merge bubbles in there? Eww!

The Why?

The workflow that caused those merges was as follows:

1. git pull (to bring local up to date)
2. hackity-hack
3. git commit
4. git pull
5. git push

By default git pull will fetch any new commits from the remote, and then merge any local changes in, resulting in the merge bubbles.

A better approach

I typically use the same workflow as above with one tweak. Rather than git pull I use git pull --rebase. The --rebase option will fetch the remote commits and rebase your commits on top of the new commits from the remote. This is the “re-writing” of history folks often talk about.

Make it better, automatically!

You can tell git to use rebase, rather than merge, in one of two ways, depending on your situation.

# Force all new branches to automatically use rebase
$ git config branch.autosetuprebase always

You can add the --global switch to have all future branches, in all repositories on this machine, behave this way.

# Force existing branches to use rebase.
$ git config branch.*branch-name*.rebase true

Get more info

Be sure to check out the git man pages for more info on what those options mean and when you may or may not want to use them.

You might also want to check out my Git Workflows repository on The GitHubs where you can find a Keynote presentation (or PDF in the Downloads) explaining git rebase vs. git merge Complete with pictures!