Geek Answers Handbook

Should I do Git Merge Develop in Master and then come back after tagging?

The question is, how do I get the correct version (shown using git describe ) when develop after I combined it into master and tagged master?

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

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

Nothing better comes to my brain, so I just combine master with development, and after that the scan 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 that it makes no sense to do, but how to achieve the correct version then?

+7
source share
2 answers

There seems to be something wrong with your use of git. If you combine develop into master , but never master - develop , then master can diverge freely - any changes to master will never fall into the develop / STRONG> branch. Therefore, your statement that they have the same commits is incorrect. Using the VonC chart,

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

The entries I named "m1" and "m2" will never "evolve". If there are no such commits - you are not doing work on the master - then when you make a merge to develop into a master, it should be a quick merge; then they will have the same commits and everything will work as you described.

The decision depends on the workflow you are trying to achieve, of course.

  • Personally, at that moment I would delete and recreate the develop branch, starting from the wizard, or the accelerated redirect to 1.6 , so 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 assume that it is based on 1.6, as it actually is.

  • If you intend that develop is a branch of continuous development, and master is a random branch of "release", you should avoid creating any commits such as m1 and m2; how much you do this, git describe tells you for sure that something else .

I'm not an expert on using git in commands, so take it all with salt.

+3
source

Given git describe , it says “looking for the last tag available from the commit”, it seems like git describe on develop go back to master in the commit, where your new 1.6 tag is not already installed.

 m(1.5)--m--m--m(1.6, master) \ / d-------d--d (develop) => git describe develop will return 1.5-xxx

After merging the development wizard

 m(1.5)--m--m--m(1.6, master) \ / \ d-------d--d---d (develop) => git describe develop will return 1.6-xxx

If other members are not working on develop , you can consider rebasing the develop branch on top of master to return the expected tag. ( git rebase )

 m(1.5)--m--m--m(1.6, master) \ d--d--d (develop) => git describe develop will return 1.6-xxx
+1
source

More articles:


All Articles