Git workflow for merging remote ‘origin/develop’ into ‘origin/master’

Question

With unlimited lifetimes for ‘develop’ and ‘master’, what’s the best workflow for merging and tagging a GitHub remote ‘origin/develop’ branch into the remote ‘origin/master’ without the remote ‘master’ getting ahead of remote ‘develop’?

Scenario for updating a file (readme) and tagging the ‘master’...

Everything agrees...

$ git log develop ^master
$ git log master ^develop
$ git log master ^origin/master
$ git log master ^origin/develop
$ git log develop ^origin/develop
$ git log develop ^origin/master

Switch to ‘develop’...

**$ git branch**
* develop
  master

Edit README.md file.

Commit to local repo...

**$ git commit -a**
[develop 47c8393] Updated branching model
 1 file changed, 18 insertions(+), 6 deletions(-)
 rewrite README.md (81%)

Push ‘develop’ to remote ‘develop’...

**$ git push origin develop**
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 745 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:xxx/xxx.git
   038cb2b..47c8393  develop -> develop

Switch to ‘master’...

**$ git checkout master**
Switched to branch 'master'

Merge ‘develop’ into ‘master’...

**$ git merge --no-ff develop**
Merge made by the 'recursive' strategy.
 README.md | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

Tag ‘master’...

**$ git tag -a v3.0.2**

Push ‘master’ to remote ‘master’...

**$ git push --tags origin master**
Counting objects: 2, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 442 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
To [email protected]:xxx/xxx.git
   038cb2b..5750fa7  master -> master
 * [new tag]         v3.0.2 -> v3.0.2

GitHub now reports remote ‘master’ is 1 ahead of remote ‘develop’ (the merge). Shouldn’t they agree?...

**$ git log origin/master ^origin/develop**
commit 5750fa78ff81f41ef2327c2f4595f98c0413e245
Merge: 038cb2b 47c8393
Author: 
Date:   

Merge branch 'develop'

If the ‘master’ is merged back into ‘develop’, the HEAD points to ‘develop’, is this a problem? Should a new ‘develop’ be branched from the new ‘master’ (not supporting unlimited lifetime for ‘develop’)?

Solution

In git, merging/rebasing occurs locally, so if you want the two remotes to agree you have to make them agree locally first.

Making the command git merge --no-ff develop on master creates a new commit on master that contains all of the commits on develop. This new commit on master is not the same as any of the commits on develop, even when there is only one commit on develop.

Using --no-ff always creates a new commit, so it will always ensure the branches are different -- the same is true if you combine commits, regardless of how.

If you want to keep the branches the same look into a workflow that uses git rebase instead of git merge, such as (A Rebase Workflow for Git).

Comments

[Todd]

After first pushing 'develop', I believe I did merge locally (from local 'master' $ git merge --no-ff develop), then tag and push to remote ($ git push --tags origin master). This results in remote master being ahead of remote develop!?!?

[Todd]

Thanks for the great link and thought David! If am am doing distributed development, and sharing the remote repo, I was under the impression that rebase may not be appropriate, the link seems to say otherwise. Do you see any concerns in that environment?

[David Culp]

The only concern I've found to be valid with rebasing is that it can be used to rewrite public history. As long as the workflow does not require a forced push, which will change the public commit history, everything will be fine. The workflow I linked is safe in this regard. I will note that others have different views, and there is a healthy argument regarding whether it is best to use git merge ... or git rebase ... -- a quick query for 'git merge vs rebase' will give you much to read on both sides if you have further concerns.

[Todd]

I'm switching to the rebase workflow in the link you provided (plop and push)! I'd vote-up your answer but I don'y have the rep to be able to do so!! Thanks David!

[Todd]

David, Still puzzled by this so I've rephrased the question... [Git Workflow, Nvie Branching Model Ahead and Behind] (stackoverflow.com/questions/15641937/…)