Should I git merge develop into master and then back after tagging?
The question is - how to achieve 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 is still belong 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?
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.
Considering git describe is about "finding the most recent tag that is reachable from a commit", it seems ok that a git describe on develop get back to master at a commit where your new 1.6 tag wasn't yet set.
m(1.5)--m--m--m(1.6, master)
/
d-------d--d (develop) => git describe develop will return 1.5-xxx
After merging master to develop
m(1.5)--m--m--m(1.6, master)
/
d-------d--d---d (develop) => git describe develop will return 1.6-xxx
If other contributors aren't working on develop , you could consider rebasing develop branch on top of master , in order to get back your 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
上一篇: 在C＃中断言权限
下一篇: 我应该混合发展成为主，然后在标签后回来？