Git pull results in extraneous "Merge branch" messages in commit log

Question

I'm working with another developer on a project, and we're using Github as our remote repo. I'm on a Mac using git 1.7.7.3, he's on Windows using git 1.7.6.

This is what's happening

One of us (let's call him developer A, but it doesn't matter which one) pushes a set of commits to GitHub.
The other (developer B) makes some local commits.
B does a git pull.
B does a git push.
Looking at the commit history log, I see Merge branch 'master' of github.com:foo/bar

The commit log gets littered with "Merge branch" messages over time, and also shows developer B as committing changes that developer A made. The only way we've found to prevent this issue has been to do a git pull --rebase at step 3, but I don't know what side effects rebasing will introduce. This is my first time working on a multi-developer git repo, so is this just normal behavior? Any thoughts on how to solve this issue?

You can view the log without merges with `git log --no-merges` — wjandrea, Jan 11 '18 at 20:59

poke · Accepted Answer · 2014-04-08T10:59:56.950

96

The commit you are seeing is perfectly fine. A pull effectively runs git fetch and then git merge so a merge is usually happening when you run git pull.

The alternative to use rebasing instead of merging is possible, but usually you should avoid it. Rebasing allows you to keep a linear history, but also removes any information about the branching that originally happened. It will also cause the history of the current branch being rewritten, recreating all commits that are not contained in the target branch (in your case, the remote). As the recreated commits are different commits, this can cause a lot of confusion when developing together with others, especially when people already checked out parts of those commits before they get rewritten (for example with feature branches). So as a rule of thumb, you should never rewrite any commit that was already pushed.

The commits you see are there to combine two (or more) branches. It is perfectly fine to have a commit that does nothing else then merging multiple branches. In fact it makes it very clear when you have a merge commit that combines branches when looking at the history. In comparison to rebasing, merging also allows you to effectively see the original history as it was developed, including the actual branches that coexisted.

So, long story short: Yes, having merge commits is perfectly fine and you should not worry about them.

edited Apr 08 '14 at 10:59

answered Dec 14 '11 at 18:08

poke

369,085
72
557
602

2

Very good answer. I myself tried the rebase style since it was recommended in some open source projects contribution guidelines, and it caused me problems. A new member in the team had the same too. I think the rebase option isn't for teams working together all day, but is correct for projects that have main contributors and other contributors who just submit patches. Those should be fine fetching main repo and rebasing their changes just before their issue a pull request. – Meligy Apr 22 '12 at 23:37
@poke, is it possible, though, there to be no changes on the github remote repository and, still, when you pull, there to be a commit of this type (merge branch master of github.com...)? I've seen that happen a couple of times. – sTodorov Nov 15 '12 at 06:32
3

@sTodorov If there are no new changes, then the fetch-part of the pull will do nothing, but the merge is still being executed. So if your current local branch is not up-to-date, it will merge the new changes into your branch. And if it can’t do a fast-forward merge (if you have diverging commits), then it will create a merge commit. – poke Nov 15 '12 at 09:47
@poke, thanks for the answer. It explains why I get the extra commit from time to time. – sTodorov Nov 15 '12 at 11:54
35

This answer makes it seem like using rebase as the OP has described is dangerous, but it isn't. Rebasing at step 3 doesn't rewrite the entire history. Only the local commits that haven't been pushed are rewritten by being reapplied on top of the new HEAD (the latest commit pushed to that branch). This prevents the extraneous merge commits and has no other side effects. – bob esponja Apr 08 '14 at 10:26
1

@bobesponja All commits that are not on the pulled remote branch are rewritten. This can include published commits from other branches, e.g. with feature branches, which others may already have accessed before. As such, yes, rebasing without thinking about what you rebase is somewhat dangerous. – poke Apr 08 '14 at 10:51
@poke which scenario would include published commits from other branches in the current branch to be rebased? The only one I can think of is by rebasing the published feature branch onto the current branch which seems to go against all the rebasing guidelines I've read. I'm interested as I fetch and rebase upstream changes rather than pulling and merging. – bob esponja Apr 08 '14 at 17:45
1

@bobesponja Yes, if you are publishing your feature branch early (because others work on it, or simply as backup), then you shouldn’t rebase it because others could already have fetched it. Rebasing then—as you say yourself—goes against rebasing guidelines which I stated in my answer. However, if you don’t publish your commits, then rebasing is fine if you want and don’t mind the linear history. But it depends on how you work, so the general answer is to avoid it unless it’s really safe. Btw. I revised my answer, so if the issue is resolved, I would appreciate if you removed your downvote. – poke Apr 08 '14 at 18:26
@poke Isn't that a different situation from the one described by the OP though? They describe two (or more) people working on the same branch, pulling each other's changes. Not rebasing already published commits. This answer[1] describes the situation I'm understanding. In the OP's case "all commits that are not contained in the target branch (in your case, the remote)" are exclusively local, non published commits. There is no branching information to be lost as the purpose is solely to pull in changes. Thanks for discussion, I removed the downvote [1]: http://stackoverflow.com/a/4675513/19927 – bob esponja Apr 09 '14 at 09:21
@bobesponja Yes, I agree, in OP’s exact case it wouldn’t be a problem, and depending on the workflow it might be the desirable action. But I think it doesn’t hurt to always mention the problems that can occur from rebasing ;) – poke Apr 09 '14 at 13:02
But, wouldn't those messages seen when I do a pull request? – Hi-Angel Sep 04 '16 at 12:22
@Hi-Angel I’m not sure what you’re referring to. What messages? – poke Sep 04 '16 at 18:28
@poke the `extraneous “Merge branch” messages in commit log` ☺ But never mind, since I commented, I pushed a code to github, and I didn't see this message there. – Hi-Angel Sep 05 '16 at 03:56
@Hi-Angel You will get that commit if the one responsible for closing the pull request decides to merge the changes, yes. But they could equally rebase it (or simply decline it ^^). But as said before, it’s not “extraneous”; it has a purpose and it’s fine being there. – poke Sep 05 '16 at 06:29
@poke no, I didn't mean PR, I just *push*ed to my fork, and though I see in the local log the message, but the github site says that I'm `2 commits ahead`, and none of them has the message. – Hi-Angel Sep 05 '16 at 06:51
Merging almost always results in a horrible mess in the history that's also impossible to bisect so I always prefer rebase. This answer spreads biased and incorrect information about rebase - please stop upvoting it! – user2061057 Nov 04 '16 at 09:28
@user2061057 Whether you prefer rebasing or not is *your* personal preference. There are people and teams that care about maintaining a linear history and there are those that don’t, or even prefer having the original branch structure persisted in the history. The things I explain about both merging and rebasing are *facts*, allowing people to form their own opinion. – poke Nov 04 '16 at 09:41
@poke your explanation makes perfect sense, in fact, this is the most appropriate way of collaborating workflow. I have a question though, why is a merge happening when the same user commiting from two different locations? For example, I updated the README.md file on GitHub and commits other changes from my desktop with the same user, and got a merge commit. Why is so? – autopilot May 14 '22 at 12:08
1

@autopilot The user doing a commit is actually not important. What matters there is that your branch on GitHub is a separate branch from the branch on your computer. If you make commits on each side without pushing or pulling in between, then you still have two branches that are diverging, so you need to merge. – poke May 14 '22 at 18:32

score 56 · Answer 2 · edited Aug 25 '17 at 11:31

56

This answer has been revised, as my understanding, diagrams, and conclusions were incorrect.

git pull causes merge commits because git is merging. This can be changed by setting your branches to use rebase instead of merge. Using rebase instead of merge on a pull provides a more linear history to the shared repository. On the other hand, merge commits show the parallel development efforts on the branch.

For example, two people are working on the same branch. The branch starts as:

...->C1

The first person finishes their work and pushes to the branch:

...->C1->C2

The second person finishes their work and wants to push, but can't because they need to update. The local repository for the second person looks like:

...->C1->C3

If the pull is set to merge, the second persons repository will look like.

...->C1->C3->M1
      \      /
       ->C2->

Where M1 is a merge commit. This new branch history will be pushed to the repo. If instead, the pull is set to rebase the local repo would look like:

...->C1->C2->C3

There is no merge commit. The history has been made more linear.

Both choices reflect the history of the branch. git allows you to choose which history you prefer.

There are indeed places where rebase can cause a problem with remote branches. This is not one of those cases. We prefer to use rebase as it simplifies an already complicated branch history as well as shows a version of the history relative to the shared repository.

You can set branch.autosetuprebase=always to have git automatically establish your remote branches as rebase instead of master.

git config --global branch.autosetuprebase always

This setting causes git to automatically create a configuration setting for each remote branch:

branch.<branchname>.rebase=true

You can set this yourself for your remote branches that are already setup.

git config branch.<branchname>.rebase true

I would like to thank @LaurensHolst for questioning and pursuing my previous statements. I have certainly learned more about how git works with pull and merge commits.

For more information about merge commits you can read Contributing to a Project in ProGit-Book. The Private Small Team section shows merge commits.

edited Aug 25 '17 at 11:31

macf00bar

673
1
14
32

answered Dec 15 '11 at 16:13

Bill Door

18,272
3
32
37

8

“Using rebase instead of merge on a pull provides the correct history to the shared repository. Using merge provides a false history.” — What’s the rationale backing up this rather bold statement? There is no way a history with merges is ‘false history’. It is an accurate depiction of the order in which things happened. What you’re doing by rebasing is actually *altering* history, to create a slightly more linear version of it. You sacrifice accuracy for aesthetics. Maybe something you prefer to do, but in no way more truthful. – Laurens Holst Jan 24 '12 at 11:44
2

Using rebase instead of merge does not sacrifice accuracy for aesthetics. We use --no-ff for merges, so aesthetics is not a requirements. Accuracy is a desire. Rebase provides that accuracy. – Bill Door Jan 25 '12 at 05:09
2

*How* is the rebased history more accurate? You don’t clarify this, and I don’t see how it would be. – Laurens Holst Jan 25 '12 at 10:50
2

History is a reflection of the time at which commits occurred in the __shared__ repo. One day 1, the shared repo saw commit C2. On day 2, the shared repo sees commit C3. If C3 came before C2 then the reflection of time would not be correct. C3 did not come before C2. All that rebase, does is re-organize the commits on the __local__ repository to properly reflect the history shown by the shared repository. – Bill Door Jan 25 '12 at 16:18
1

I don’t see why that first sentence would be true. This is how it works with SVN, but that’s more of an artefact of its limitations than an actual reflection of history. SVN forgets everything that happened locally, while Git records it. By rebasing instead of merging you’re filtering this out. I’m perfectly fine if this is what you want to do, but it is an aesthetic choice, and claims that a history which does not do this filtering would be *false* are absolutely un-true. It is a more complete representation history. – Laurens Holst Jan 26 '12 at 10:37
7

Your questions caused me to review my understanding of merge commits. My diagram is incorrect. I am revising the discussion. My conclusions are also incorrect. The history for rebase and merge are equally correct. You can make your own choice. – Bill Door Jan 26 '12 at 16:23
1

Upvote for simple ascii art graphical representation of the difference. Accepted answer doesn't have it – Green Jan 22 '18 at 07:23

score 15 · Answer 3 · answered Oct 11 '15 at 20:57

15

You can do:

git pull --rebase

However, this will always put your changes on top of your collaborators'. But you won't get any polluting merge message.

answered Oct 11 '15 at 20:57

gaborous

15,832
10
83
102

score 12 · Answer 4 · answered Jan 10 '17 at 22:12

12

There is actually a much simpler answer to this. Just have developer B do a pull BEFORE making his commit. This will prevent those merge commits, since they're caused by the history you've created on your local repo from your local commit trying to merge with the history of the commits on the remote repo. If you get a message saying something along the lines of 'changes will be overwritten' when doing a pull, it just means you both touched the same file, so do:

git stash
git pull
git stash pop

then you can resolve any merge conflicts if there are any.

answered Jan 10 '17 at 22:12

Luke

648
7
15

Most annoying and anxious are exactly merge conflicts. I rather avoid it – Green Jan 22 '18 at 07:27
1

@Green If you're worried about merge conflicts then even git pull's no different. – Zoso Feb 13 '18 at 05:46
Except that one time when you forget to `stash` before you `pull`. Ugh git requires me to be at the top of my game all the time. – linuxNoob Feb 05 '19 at 20:15
Need to `git pull --rebase` to integrate remote changes before the local ones, regardless. – vonbrand Jun 17 '19 at 12:30

score 7 · Answer 5 · answered Dec 14 '11 at 18:08

Doing a git pull will insert the "Merge branch" messages, that's just what it does. By doing a git pull, you have merged the remote branch into your local branch.

When you do a git pull and there are conflicts, the git log will show the updates to the conflicted files as coming from the user that resolved the conflicts. I assume this is because the person that fixes the conflict re-commits the file.

As far as I know that's just how git works, and there is not a way around it.

Rebasing will blow away the git history, so you won't be able to see when merges occurred.

Himanshu Verma · Answer 6 · 2021-06-27T07:19:28.240

Solution:

If other developer had made their commits on remote, then you need to take git pull before doing your commit. If you do in this way you will never get extraneous “Merge branch” messages in the commit.

If in case you committed before taking git pull, then you need to take git pull --rebase and then you won't get extraneous “Merge branch” messages in the commit.

Also, Know these things:

git pull --rebase What’s happening here? Git will rewind (undo) all of your local commits, pull down the remote commits then replay your local commits on top of the newly pulled remote commits.
That's how the commit-graph looks when you push that extraneous “Merge branch” commit along with your commits.

And, that's how the commit-graph looks when you take a prior git pull or take git pull --rebase after your commit.

Note:

The difference in the number of commits you made in both the cases and the branch structure.
Also, all this happens on the same branch, the branch gets merged with itself.

score 1 · Answer 7 · answered May 12 '22 at 07:23

in my case i accidentally set some config with git config -e and git config --global -e for a project which caused the problem. i fixed it by removing both added configs. forexample i had these two lines in global config :

[pull]
    ff = false

and also in local config i had :

[pull]
    rebase = off

when i removed these two configs, i could pull changes without causing a merge commit.

Git pull results in extraneous "Merge branch" messages in commit log

7 Answers7

Linked