Question

We’re a small using Git and all us are new to it. In the month or two that we’ve used Git and began experimenting with feature branches and release branches, we’ve run into little spaghetti incidents like this one caused by merge conflicts, etc:

The black line is my development branch. Ignore the red one. You’ll see how one single commit has broken away from that development tree and then merged back. Is it possible to clear out some of these old cobwebs by flattening the tree? My head is now about 500+ commits away from this.

I’ve read that this can be avoided by rebasing instead of merging.

Even though, it’s a trivial thing, I’d like to fix this if possible both as a matter of a OCD and clarity.

Thanks.

Answer 1

If you really want to linearize the history after a commit A on the master branch, you could always do:

git checkout master
git rebase A

However, this means that you’re rewriting the history of your master branch, so if you do (force-) push this new version, you’ll have to brief everyone in your team about how to fetch the new version and reset their master branches to match the rewritten version. Otherwise, people are likely to pull, which will merge the rewritten branch with their existing one, defeating the object of the exercise.

These small divergences typically happen when someone creates a commit on their master branch, but master on the server has moved on in the mean time – this means that when they pull again, a merge commit is required. You can avoid this in the future either by measures like:

• Encouraging people to use git pull --rebase
• Telling people to use the branch.<name>.rebase and branch.autosetuprebase config options, so that they don’t forget to add the --rebase
• Adding a hook to the server that refuses pushes of non-linear history

However, personally I don’t mind seeing these merges in the history – with a good history viewer it’s still very clear what’s going on.