Git avoiding “merge branch master”

Question

A colleague and I are using git with a single remote origin repository. We both Commit local then push to origin. As we are working there is naturally some divergence.

Once its time to push to origin i would suspect we can merge local, then push to origin. I anticipated to get a rather straight version history without described merges.

Judging from the rather complicated version Subway Map and the ever recurring Merge branch 'master' message i guess we are doing something not quite right.

• What is the reason for the "merge branch to master" messages?
• How can this version history be simplyfied?

I have the feeling this has been answered here before but I couldn't fully understand the information I gathered.

Answer 1

We have a case that is similar. Though we use a central master repo, we often have individual developers generating the Merge branch 'Master' message. Our solution was to have developers do git pull --rebase whenever pulling from the remote master repo.

Answer 2

I think you are looking for git rebase .

Each of the merges recorded in your history was required from the "preserve true history" point of view. Your branches diverged at this point, and were subsequently merged (note how both branches have commits unique to them, so fast-forwarding isn't possible.

If you rebase, the current tip (including the changes from your colleague) becomes the new branch point, and unless they push in between, your changes can then be applied by a fast-forward, giving the impression of linear development (but with non-monotonic timestamps).

Answer 3

You are doing everything right. You are developing concurrently, you are integrating the changes of your peer from time to time, and git faithfully records exactly this history.

While you can "avoid" the merge commits by rebasing, it is generally better to stick with the mergy history: Whenever you rebase a commit, you are effectively creating a new commit, one which tells a lie about how it came to be. And, while those lies usually are benign, they can cause trouble later on. This is especially true if you skip rerunning your test suit on each and every rebased commit.

I think, the whole idea of "creating a linear history" is a bit of misguided cleanliness. You don't really want a linear history. You want a true history, one where each and every single commit was actually tested. Because that allows you later on to run git bisect with a meaningful result.

---

TL;DR: Don't change your habits. They are good as they are. And you may be thankful for them in the future.