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
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:
develop
branch pointer ahead, so that it points to the latest commit in origin/develop
. This is known as a fast-forward merge.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