Should I Git Merge Develop Into Master and Then Back After Tagging?

Question

The question is: how do I achieve the correct version (shown with git describe) on develop after I merged it into master and tagged master?

I use common git branching - master for production. Let's say git describe shows 1.5 on master, and, after merging with develop, master shows 1.5-234-g1e894af.
So I create a new annotated tag with git tag -a 1.6 and thus git describe master now shows 1.6.

BUT: git describe develop still shows 1.5-something, which is strange as for me - it has same commits as in master - why Git thinks it still belongs to 1.5 version?

Nothing better comes into my brain, so I just merge master into develop, and after that develop shows version 1.6-2-... which is acceptable but produces 1 more useless merge commit, and warns me about "merge made by recursive" which I also think makes no sense to do, but how to achieve correct version then?

Answer 1

It sounds like something is wrong with your use of git. If you are merging develop to master, but never master to develop, then master is free to diverge — any changes on master will never get into the develop branch. Therefore your statement that they have the same commits is false. Using VonC's diagram,

m(1.5)--m1--m2--m(1.6, master)
 \              / 
  d-------d----d (develop)

The commits I've labeled "m1" and "m2" will never get onto "develop". If there are no such commits — you do no work on master — then when you do a merge of develop into master it should be a fast-forward merge; they would have the same commits then, and everything would work as you have described.

The solution depends on the workflow you're trying to achieve, of course.

• Personally, I would at this point either delete and recreate the develop branch starting from master, or fast-forward it to 1.6, so that when you continue working on develop you have this structure:

  m(1.5)--m1--m2---m(1.6, master)
   \              / \ 
    d-------d----d   d--d (develop)
  

  Then git describe will consider it to be based on 1.6 as it actually is.

• If your intent is that develop is a continuous development branch, and master is the occasional "release" branch, then you should avoid creating any commits like m1 and m2; insofar as you do, git describe is accurately telling you that something is different.

I'm not an expert on using git in teams, so take all of this with a grain of salt.