Rebasing Merge Commits in Git (a cautionary tale for software teams)

The problem with the default git pull is that it treats every "give me what's up on the server" as a first class merge commit.

It adds a lot of noise to the commit history if you're trying to differentiate between "oh, this bug fix or feature was added into master/trunk/whatever" and "oh, that was just bob getting the lastest code from upstream"

Well, a couple of things. If you look at a branching model such as that described by Vincent Driessen [1], you start to appreciate the amount of information encapsulated by branches and merges in the history. In a fast-moving project with several developers, glancing at the history becomes the easiest way for each developer to keep track of what the rest of the team has been working on.

Thus, anything that introduces noise to the history reduces the value of the information it contains. But 'git pull' is even worse than this - it actually creates 'misleading' history:

Each merge commit has (at least) two parents, the first of which is special in a subtle way - it's the commit you were _on_ when you merged the changes _in_. So, with a nice history, you can follow a branch back in time by following the first parent of each commit.

When you 'git pull', the merge commit has your local changes as the first parent, and the rest of the team's changes look like a separate chunk of work merged in.

Git-bisect is an extremely useful tool for searching the history for the commit that introduced a problem, but a history full of misleading merges dramatically reduces its usefulness.

Still, YMMV, the costs of keeping a good history may outweigh the benefits for you and your team. For me and mine, it's definitely worth it.

[1] http://nvie.com/posts/a-successful-git-branching-model/