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).