我应该将Develop合并到Master然后在打标签后再回退吗？

Question

我应该将Develop合并到Master然后在打标签后再回退吗？

9

问题是：在将develop合并到master并标记了master后，我如何在develop上实现正确的版本（使用git describe显示）？

我使用常见的Git分支管理方式- master用于生产。假设git describe在master上显示1.5，在与develop合并后，master显示1.5-234-g1e894af。
因此，我使用git tag -a 1.6创建了一个新的注释标签，因此git describe master现在显示1.6。

但是：git describe develop仍然显示1.5-something，这对我来说很奇怪-它具有与master相同的提交记录-为什么Git仍然认为它属于1.5版本？

我没有更好的想法，所以我只是将master合并到develop中，之后develop显示版本1.6-2-...，这是可以接受的，但会产生一个无用的合并提交，并警告我“merge made by recursive”，我认为这也没有意义，但如何实现正确的版本呢？

- Denis Chmel

2个回答

2

考虑到git describe是关于“查找可从提交访问的最新标签”的，因此在develop上执行git describe返回到master上一个您的新1.6标签未设置的提交似乎是可以接受的。

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

合并主分支到开发分支后

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

如果其他贡献者没有在develop上工作，您可以考虑将develop分支rebase到master上，以获得您期望的标签。（git rebase）

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

- VonC

是的，这正是我想象中的图片。Rebase 当然不利于团队合作，而且会更改提交 ID（我们在 bugtracker 中引用它们）。尽管如此，我仍然认为应该有一种方法可以仅回溯合并标签。这肯定是一个常见的问题，我怀疑并非每个人都在进行 rebase 或者回溯合并 :) - Denis Chmel

“master到develop”的合并（图2）不应该是快进合并（将“develop”置于“master”提交记录处）吗？ - ysdx

@ysdx：我在画图时有你的“生成无用提交”的想法。这个想法仍然是，只有在将“master”合并回“develop”之后，“git describe”才会返回1.6。 - VonC

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Kevin Reid · Accepted Answer

看起来你在使用git方面出了一些问题。如果你正在将develop合并到master，但从未将master合并到develop，那么master就可以分叉——在master上的任何更改都不会进入develop分支。因此，你关于它们具有相同提交记录的说法是错误的。使用VonC的图表，

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

我已经将标记为"m1"和"m2"的提交排除在“develop”分支之外。如果没有这样的提交，您在主分支上不进行任何工作，那么当您将develop合并到主分支时，应该是一种快进式合并；它们将具有相同的提交，然后一切都可以按您所描述的方式进行。

当然，解决方案取决于您要实现的工作流程。

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.

我不是团队中使用git的专家，所以请对我的意见持保留态度。