为什么我应该使用标签与发布/测试版分支进行版本控制？答案

【问题标题】：Why should I use tags vs. release/beta branches for versioning?为什么我应该使用标签与发布/测试版分支进行版本控制？
【发布时间】：2012-04-06 07:01:03
【问题描述】：

我已经使用 git 大约一年了，并且想使用标记来标记不同版本的提交。我找到了很多关于用于处理标签的命令的信息，但我想知道的是，如果我可以创建一个名为 1.1.0 的新分支而不必让我的头脑混乱，为什么还要使用标签有一套全新的 git 命令？

标记而不是分支必须有很多充分的理由，但我想知道这些优势是什么。

【问题讨论】：

标签： git branch git-tag

【解决方案1】：

分支和标签是一回事（指向提交的指针，又名"ref"），除了分支自动移动到下一个提交，而标签在同一个提交上永远保持¹。 p>

在发布版本时，您通常希望标记构建该版本的代码的“快照”，并且即使您继续改进代码，您也希望它保持这种标记，因此您会使用一个标签。

如果您尝试为此使用一个分支，它可能会无意中移动到另一个提交，而该版本是不是构建的。

¹ 当然，除非你删除标签。

注意：我意识到这是一个老问题，但我觉得分支和标签之间的相似性（和一个关键区别）并没有在其他答案中得到尽可能清楚的充实。 em>

【讨论】：

亲爱的@downvoter，有什么具体的理由投反对票吗？
我没有否决你的答案，但你所说的“分支自动移动到下一个提交”是什么意思？分支不会自动移动到任何提交。运行git commit 更新签出分支的头部以引用新提交，是的，但没有其他分支“自动”移动到下一个提交。您应该澄清答案的第一段。
@Toothbrush 当然，这就是我所说的“自动移动”。然而，分支并不真正“拥有”任何提交，它甚至不指向一组提交，它只是指向一个提交（其余的可以通过遍历提交图来暗示，有时并不精确）。在 git 下，branch 只是.git\refs\heads 下的一行文件，包含提交的哈希。提交自己不会“记住”哪个分支创建了它们。这与 Mercurial 不同，例如，分支信息可以写入提交的元数据。
是的，但很多人不知道这一点——尤其是那些对网上建议的使用 Git 做事的无数方法感到困惑的新手。

【解决方案2】：

除了其他答案，这是我的 2 美分。

简答：为发布版本使用标签

长答案：我相信专门使用标签进行发布版本控制比使用分支更好。如果您需要更新版本，只需从标记的提交分支，一旦您完成该分支（很可能是修补程序分支）的工作，请在该新分支的头部创建一个带有新版本的新标签。然后，将该分支合并回 master/develop，因为您真的不应该更改发布版本，除非它是可能应该合并回源代码的修补程序。然后删除该分支，因为它不再需要。如果您需要对该新版本应用另一个修补程序，请重复相同的步骤。

请参阅以下文章中显示如何将修补程序与作者的 Git 工作流程合并的部分 - https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2

【讨论】：

【解决方案3】：

标签是不可变的。

虽然您可以创建一个名为“1.0.0”的分支 - 您或任何拥有提交权限的人也可以简单地推送到该分支（有意或无意）并更改 1.0.0 的含义。

一旦你创建了一个标签，你就不能用标签做到这一点——就是这样；标签 1.0.0 就是这个意思，不能更改^*。

这是标签和分支之间的主要实际区别

^*您可以删除并重新创建标签，从而更改标签，但绝非偶然。

【讨论】：

【解决方案4】：

标签主要用于将来参考项目的特定版本，通过标记提交。当然，你总是可以使用分支，但是如果你经常更改版本，你最终会得到很多未使用或很少使用的分支。

实际上，无论如何，标签都是没有分支的分支，只是添加了一种引用项目特定版本的方法以降低复杂性。

编辑：Here 是使用 git 的好方法，我用于所有项目。

【讨论】：

Heh(: 这真是一个很棒的工作流程，涵盖了所有可能的解决方案。
是的，我以前见过nvie方法，并且被它弄糊涂了。尽管如此，一旦我理解了它，我渴望实现它。我想使用标签，您不会意外更改代码、提交并仍然处于同一版本。有了分支，它可能会在不经意间发生。标签似乎是一种更安全的标记发布方式。
nvie 方法的美妙之处在于我一开始不需要了解它。我可以找到我想做的部分并输入命令。几次之后，它变得很自然，几天后我像专业人士一样在树枝上跳舞！
希望通过盲目地应用它来理解 gitflow 方法会让您错过所有可以针对您的情况应用的简化。而且 gitflow 确实不适合大多数团队：要么过于复杂，要么过于简单。
如果不是为了编辑，我会给这个一般概念+1。在 2020 年，如果您可以选择分支模型，您可能不想严格遵循 git-flow。使用develop 分支的最低要求不再是常见的做法，这也是有充分理由的，因为它在具有适当管道的快速发布周期设置中没有什么优点。

【解决方案5】：

我倾向于使用同时包含标签和分支的工作流程。标签非常适合标记已发布的代码或显着的开发版本。分支有助于跟踪与特定版本相关的所有更改。

这里有一篇关于这种工作流的好文章：http://nvie.com/posts/a-successful-git-branching-model/

【讨论】：

【解决方案6】：

您使用标签来记录历史上的重要提交。 “这是我们在构建服务器崩溃的那个下雨的星期四为此版本使用的确切提交”。如果您使用分支而不是标签，您将永远无法知道您使用的确切提交。你只知道“我们在这个分支的某个地方发布了 1.1.0 版本”，除非你手动写下那个提交的确切哈希，这就是你首先使用标签的原因:)

【讨论】：

我认为他的意思是创建一个名为 1.1.0 的分支并且不再使用它，因此它将代表命名版本中的项目。