version control - Why does git merge a branch into itself?

Question

I awoke this morning and looked at the commit history of one of my dev team's private repositories on BitBucket. I saw this:

Anonymous committed fcde879 MERGE

Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop

This is, uh, somewhat unusual. My guess was that this was pushed from a new machine that didn't have git configured properly. Still, I was not sure why it was doing this. On BitBucket, it shows two separate hashes as the commit parents, but it does not have the "view raw commit" option of other commits.

I checked out that branch, pulled, and looked at the log manually.

sidious@DS-1:/path/to/repo$ git log -1 --format=raw
tree 2931d14f48e61eaf0bbe0660af5b5dd76c07f063
parent 6bb38dee681df7620ffa42b6790641a7873166f2
parent f59c82e19e3e79310a53e273bab78139c49ff063
author root <root@somemachine> 1437069530 +0000
committer root <root@somemachine> 1437069530 +0000

Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop

As far as I can tell, the 6bb parent is on the develop branch and the f59 parent appears to be from a different branch. It is kinda hard to tell what is going on.

I searched but could not find an answer, and I need to get back to the grind, thus I posit my query here: why is git merging a branch into itself? Or, rather, why is this nomenclature being used as the commit message?

question from:https://stackoverflow.com/questions/31463025/why-does-git-merge-a-branch-into-itself

Answer 1

This scenario is not unusual.

The key here is that the branches being merged are different: it's the remote repository's develop branch being merged into the developer's local (working) develop branch.

In the developer's local repository there are two distinct branches:

• develop = The branch he/she is currently working on. The new commits go here.
• origin/develop = This is essentially a snapshot that the current repository holds about the state of the develop branch on the remote server. It gets updated with the remote changes when you do fetch or pull, and with the local changes after a successful push.

Now, when you do git pull, two things happen. This is because git pull is essentially an alias for other two git operations: fetch and merge:

• fetch - brings all new commits (if any) from the remote repository to the local origin/develop branch.
• merge - takes the new commits and applies them to the local working develop branch. This can happen in one of two ways:
  • if the local working branch does not contain divergent history (new commits that the remote does not know about), then it simply advances the develop branch pointer ahead, so that it points to the latest commit in origin/develop. This is known as a fast-forward merge.
  • if the developer has some new commits of his own that are not present in the remote repo, and, therefore not in the origin/develop branch, then a regular merge is done, meaning that there's a new commit, containing the changes from both branches. By default, git assigns messages like these to such commits: Merge branch 'develop' of https://bitbucket.org/abc/xyz into develop.

So, the scenario is a pretty common one.

Now, if this happens very often and you don't like to see very complex commit history graphs containing commits like the one we're talking about, try looking into using rebase instead of merge.

You can do this two ways (when getting the changes from the remote server):

• git fetch; git rebase
• git pull --rebase