Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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 git@github.com: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 git@github.com: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’)?
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).
                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?
– Todd
                Mar 25, 2013 at 0:28
                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.
– David Culp
                Mar 25, 2013 at 2:24
                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
                Mar 25, 2013 at 14:40
                David, Still puzzled by this so I've rephrased the question... [Git Workflow, Nvie Branching Model Ahead and Behind] (stackoverflow.com/questions/15641937/…)
– Todd
                Mar 26, 2013 at 17:33
                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
                Mar 24, 2013 at 17:59
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.