使用gitflow时应该标记发行分支或主分支吗？

此问题表明：

根据我的理解，在合并之前将标签放置在release分支上（而不是在master分支上）实际上是正确的做法，也可以通过develop describe分支的git describe --tags找到它。参见＃374

而另一篇文章：

我今天不小心通过自制软件安装了0.4.2-pre版本，并且对标记在该版本中的工作方式感到困惑。先前（版本0.4.1），在将发布分支合并到主分支之后，该标签已在master分支上创建。现在看来，标记是在release分支的最后一次提交上创建的，这对我来说不是一个好主意。特别是如果您有一个依赖git标记的构建系统，并且如果HEAD是带标记的提交则创建发行版本，而如果其以下提交之一则创建开发版本。有人可以向我解释此更改背后的逻辑吗？对于语义版本控制，我不认为这是补丁程序级别的颠簸！

在我们的团队中，我们对此进行了多次讨论。有些表示需要从master分支创建标签，而另一些则倾向于使用release分支。根据gitflow的图片：

好像标签已放置在母版上。

首先，您不能标记分支，只能标记提交。

您应该标记实际释放的提交。这就是版本标记提交的重点。如果您的软件在某些环境（生产环境或其他环境）中存在问题，则可以放心地说该问题是由发行该版本的提交引起的。

（这就是为什么人们谈论“可复制的构建”的原因：因此，他们可以确信发布过程不会引入预览/过渡环境中不存在的新错误，并且如果他们在生产中存在错误，他们进行调试时，二进制文件正在其计算机上运行。）

将底部的第二个绿色提交（提交的绿色子项标记为“ Only bugfixes！”）标记为“ v1.0”是没有意义的，因为您没有将提交提交到生产环境。您已释放对master的提交。您甚至可以看到git flow已将其标记为“标记1.0”。

请记住，标记的目的是：轻松查找提交。您可以将提交标记为“ v1.0”，以便可以轻松找到以1.0版发布的内容。您并不是为了在提交树中某个位置的“ v1.0”标签模糊地靠近实际释放的提交而对其进行标记。

如果您在从开发分支中找到标签时遇到问题，那将是完全独立的问题。修复用于查找标签的工具。或更妙的是：不要使用git-flow。由于可爱的彩色圆点和布置精美的线条，在该图中看起来不错，但实际上，它看起来像是疯狂的杂乱的彩色线条和圆点网。