Git Workflow, Nvie Branching Model Ahead and Behin

Question

Following Nvie's git branching model, why do I end up with 'develop' and 'master' each 1 ahead and 1 behind the other after merging the same 'release' branch into both? If the same 'release' branch is merged into each, shouldn't master and develop agree?

x   84a628d      (origin/develop, develop) Merge branch 'release-v3.0.1' into develop
|\  
| | x   2e4d60b  (HEAD, v3.0.1, origin/master, master) Merge branch 'release-v3.0.1'
| | |\  
| | |/  
| |/|   
| x | 716ce96    (release-v3.0.1) Version 3.0.1
|/ /  
x | fe3b54d      Some more more code
x | 3683892      Some more code
x | 8c0b835      'develop' branch code
|/  
x   d051b54      (v3.0) Baseline merge. Merge remote-tracking branch 'origin/master'

$ git log origin/master ^origin/develop

commit 2e4d60b7d6760b4f6b2328ab06150b020b0d279f
Merge: d051b54 716ce96
Author: Todd 
Date:   Tue Mar 26 11:27:59 2013 -0400

Merge branch 'release-v3.0.1'

$ git log origin/develop ^origin/master

commit 84a628d96653ed196faa6387c8b208badf23aa75
Merge: fe3b54d 716ce96
Author: Todd 
Date:   Tue Mar 26 11:31:53 2013 -0400

Merge branch 'release-v3.0.1' into develop

What am I missing?

Answer 1

git log origin/master ^origin/develop

This command displays all commits reachable from origin/master but not from origin/develop

git log origin/develop ^origin/master

This command displays all commits reachable from origin/develop but not from origin/master

The output from both these above commands seem to be consistent with the graph you've shown.

If you intend to find out the difference in the contents of the 2 branches, you should be using the git diff command instead.

git diff origin/master..origin/develop

If you want only the list of files which are different, you can use the --name-status option:

git diff --name-status origin/master..origin/develop

In git, a commit's SHA1 is calculated based on the parent commit's SHA1, the commit message, the timestamps, and lot of other such information. Although you've merged the same release-v3.0.1 branch into both master and develop, you've done it as 2 independent merges at 2 different time instants. This would obviously not produce the same commit SHA1 for both.

What you should've done instead is one of the following:

Option 1:

git checkout master:
git merge release-v3.0.1

git checkout develop:
git merge master

git checkout master
# This would be a fast-forward merge
git merge develop

Option 2:

git checkout develop:
git merge release-v3.0.1

git checkout master:
git merge develop

git checkout develop
# This would be a fast-forward merge)
git merge master

This way you would end up with both master and develop branches pointing to the same commit.

You could get to the same state even now by merging either master into develop or the other way around, and doing a fast-forward merge on the other branch.

git checkout master
git merge develop

git checkout develop
# This would be a fast-forward merge
git merge master