Why does git merge a branch into itself?

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