为什么我应该使用标签vs. release / beta分支进行版本控制?


114

我已经使用git大约一年了,并且想使用标记来标记不同版本的提交。我已经找到了用于使用标签的命令的大量信息,但是我想知道的是,为什么只要我可以创建一个新的分支1.1.0而不用全神贯注,就为什么要使用标签?新的git命令集?

有很多很好的理由来标记而不是分支,但是我想知道这些优点是什么。

Answers:


96

标签主要用于将来通过标记提交来引用项目的特定版本。当然,您始终可以使用分支,但是如果您对版本进行了很多更改,最终将导致大量未使用或很少使用的分支。

实际上,标签是分支而不是分支,只是增加了引用项目特定版本的方式以降低复杂性。

编辑:是使用git的好方法,我在所有项目中都使用了git。


嘿(:这真是一个伟大的工作流程,涵盖所有可能的解决方案。
哈坎Deryal

是的,我以前见过nvie方法,并且对此颇为困惑。尽管如此,一旦我理解它,我便渴望实现它。我想有了一个标签,您就不会不小心更改代码,提交并仍然使用相同的版本。对于分支机构,它可能会无意间发生。标签似乎是标记发布的一种更安全的方法。
wufoo 2012年

2
对我而言,nvie方法的优点在于我一开始不需要了解它。我可以找到要执行的操作的部分,然后键入命令。几次之后,它变得很自然,几天后,我像专业人士一样在树枝上跳舞!
Killroy

希望仅仅通过盲目地应用它来理解gitflow的方法,这会让您错过针对您的情况可能适用于它的所有简化方法。gitflow对于大多数团队来说确实是不合适的:过于复杂或过于简单。
toolforger

151

标签是不可变的

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

创建标签后,就不能使用标签来做到这一点-就是这样;标签1.0.0就是这个意思,并且不能更改*

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

* 您可以删除并重新创建标签,从而更改标签,但是当然不是偶然的。



18

分支和标签是相同的东西(指向提交的指针,也称为“ ref”),只是分支自动移至下一个提交,而标签在同一提交上永远保持1

发布版本时,通常需要标记构建该版本所依据的代码的“快照”,并且希望在继续开发代码时以这种方式保持标记,因此可以使用标签。

如果您尝试为此使用分支,则它可能会无意间移至构建发行版的其他提交。


1当然,除非您删除标签。

注意:我意识到这是一个古老的问题,但是我认为分支和标签之间的相似性(和一个关键差异)并未像其他人那样清楚地被充实。


亲爱的@downvoter,您是否有任何特定的原因?
布兰科·迪米特里耶维奇

我没有拒绝您的答案,但是“分支自动移至下一个提交”是什么意思?分支不会自动移动到任何提交。运行会git commit更新检出的分支的头以引用新的提交,是的,但是没有其他分支“自动”移至下一个提交。您应该澄清答案的第一段。
牙刷'18

1
@牙刷当然,这就是我所说的“自动移动”。但是,branch并不真正“拥有”任何提交,甚至不指向一组提交,而仅指向一个提交(通过遍历提交图可以隐含(有时不精确地)其余的提交)。在git下,branch只是位于下的单行文件.git\refs\heads,其中包含提交的哈希值。承诺自己不会“记住”哪个分支创建了他们。例如,这与Mercurial不同,后者可以将分支信息写入提交的元数据中。
布兰科·迪米特里耶维奇

是的,但是很多人不知道这一点,尤其是对于那些在网上建议使用Git做事的方式不一的人感到困惑。
牙刷'18

6

您可以使用标签来记录历史中的重要提交。“这是我们在构建服务器中断的那个雨天星期四用于此版本的确切提交”。如果使用分支而不是标签,则永远无法知道所使用的确切提交。您只知道“我们在此分支的某个地方发布了版本1.1.0”,除非您手动记录该提交的确切哈希,这就是为什么首先使用标记的原因:)


4
我认为他的意思是创建一个名为1.1.0的分支并且不再使用它,因此它将以命名版本表示该项目。
哈坎·德里亚

2

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

简短答案:将标签用于发行版本

长答案:我相信使用标签专门进行发行版本控制比使用分支更好。如果您需要更新版本,只需从标记的提交分支,然后在该分支上完成工作(很可能是修补程序分支),就可以使用新版本在该新分支的开头创建一个新标签。然后,将该分支合并回master / develop中,因为您实际上不应该更改发行版本,除非它是一个修补程序,很可能应该合并回您的源代码中。然后删除该分支,因为它不再需要。如果需要将另一个修补程序应用于该新版本,请重复相同的步骤。

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.