CODEWITHSUNDEEP
gitmergegit-remote
Todd
Todd

Reputation: 35

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

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

Upvotes: 2

Views: 23019

Answers (2)

David Culp
David Culp

Reputation: 5480

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

Upvotes: 2

vonbrand
vonbrand

Reputation: 11831

You should merge local braches, and push out the result. I.e., merge develop into master. If you don't want to mess up local branches, create branches just for this, do the merging an pushing back, and remove them. Or even create a clone just for this.

Upvotes: 0

Related Questions