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’)?
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).