git标签是否有标准的命名约定？

Question

我见过很多项目在Git中使用v1.2.3作为标签的命名约定。 我也见过一些人使用1.2.3。是否有官方认可的样式，或者有没有使用其中任何一个的好理由？

- troelskn

---

有43个赞同票，我在想这个非常有价值的问题是否可以重新措辞并重新开放，以一份涵盖所有要点的好摘要回答，并置于顶部？ @PeterEisentraut的回答似乎最完整；而目前被接受的答案似乎有点误导。（在阅读所有要点后，我认为我会使用v1.2.3作为标签。） - HostileFork says dont trust SE

Stack Overflow (SO) 用于解决代码问题。最佳实践似乎应该放在 https://softwareengineering.stackexchange.com/ 或 https://codereview.stackexchange.com/ 上。 - Cees Timmerman

看一下 https://semver.org（语义化版本控制），这应该会给你一些想法。 - vonbrand

我的经验告诉我要使用稍微不同的方案。

1. 子目录：Git标签至少应该以v/开头，这样可以将标签分组到一个命名空间中。
2. 理想情况下，标签还应包含一个唯一标识应用程序的缩写。

例如：v/myapp/1.0。这使得git仓库合并更容易：如果应用程序被合并，标签在标签命名空间中不会发生冲突。 - axd

有另一个微妙的原因支持和推广在标签中使用v前缀：这迫使工具、库和语言始终将版本识别为字符串，否则它们可能会将1.10视为浮点数，并认为它实际上是完全错误的版本1.1。在规模上，v前缀已经被证明是避免版本“乱码”损坏的好方法。然后，真正需要真实版本的工具可以轻松地去掉前导v。 - Philippe Ombredanne

回答已被阻止。但是没有答案有重要信息：您必须避免使用字符“〜”，“^”，“：”，“\”，“？”，“[”和“*”，以及具有特殊含义的序列“..”和“@ {” revparse。它也不能包含空格。这是标签名称的正确验证。我不确定这是否是完整的验证，但是...至少这是关于该主题的一些基本信息。 - Andrew_STOP_RU_WAR_IN_UA

Answer 1

语义化版本控制的1.0.0版本，由GitHub的知名人士Tom Preston-Werner发布，包含一个子规范来解决此问题：

标签规范（SemVerTag）

如果您使用版本控制系统（Git、Mercurial、SVN等）存储代码，则应使用此子规范。使用此系统可以使自动化工具检查您的软件包并确定语义化版本控制的合规性和发布版本。

1. 在版本控制系统中标记发布时，版本的标签必须为“vX.Y.Z”，例如“v3.1.0”。

然而，在讨论之后，这个概念被移除了，在SemVer规范的最新版本（编写时为2.0.0）中不再存在。同一地方的后续讨论主题进一步深入探讨，并导致一个新的“v1.2.3是语义化版本吗？”被添加到SemVer的master分支的FAQ中，但截至撰写此文（两年多以后），此更改仍未在正式发布的规范中出现。

- peritus

---

谢谢 - 这已经非常接近了。不过我希望他能解释一下为什么需要加上v。 - troelskn

@troelskn @mojombo == Tom Preston-Werner - peritus

更新链接：https://github.com/mojombo/semver.org/issues/1 - Josh Lee

语义化版本号1.0.0采用格式"v1.2.3"，而语义化版本号2.0.0-rc.1可能使用格式"1.2.3"。标签规范（SemVerTag）文章已从规范中删除。详情请参见：http://semver.org/。 - petrnohejl

这篇回答是在旧的语义化版本（版本1.0）存在时完成的。现在，在语义化版本2.0中，前缀“v”已经被移除。 详情请参见下面的帖子。 - vitalii

Answer 2

假设您也遵守一些合理的标准来对发布进行编号，似乎有两种主导的约定：

• v1.2.3
• 1.2.3

"

v1.2.3的优点在于Git文档（以及Mercurial文档）在其示例中使用该格式，并且一些“权威机构”如Linux kernel和Git本身也使用它。（提到的Semantic Versioning曾经使用过，但现在不再使用。）

1.2.3的优点在于gitweb或GitHub可以自动提供一个tarball或zip下载，形式为packagename-$tag.tar.gz（我认为tarball不应命名为package-v1.2.3.tar.gz）。另外，您可以直接使用git describe生成tarball版本号。对于没有正式发布流程的轻量级项目，这些可能非常方便。还应注意的是，语义化版本控制绝不是唯一或普遍接受的版本编号标准。值得注意的项目，例如GNOME以及无数其他项目都使用1.2.3标签命名。

我认为现在可能已经太晚了来统一这些立场。始终保持一致并讲道理。

"

---

更新：如此处评论中所述，GitHub现在提供了一个没有标签中的“v”的tarball名称。

- Peter Eisentraut

---

关于 GitHub 和 tarball 生成：这已经不再相关了。他们删除了标签中的 'v'。 - dr0bz

在按字母顺序排序标签时，在标签前加上“v”前缀也非常有用。可能存在其他标签；无论是官方存储库中的还是用于跟踪开发人员本地工作的标签。使用“v”前缀后，发布标签形成自己的分组，而不是散布在命名空间的其他位置。 - Robie Basak

更新了答案以反映SemVer不再使用“v”。 - Adam Spiers

Answer 3

之前提到的“v”是有历史原因的。早期版本的SCCS（cvs、rcs）不能区分标签标识符和修订号。为了能够检测修订号，标签标识符被限制为不能以数字开头。

- Bill Door

---

+1：好的第一次回答，并且来自我最喜欢的书籍之一的名字 :-)也许你的下一个回答将涉及一个更流行的问题，但不要改变原句的意思。 - johnsyweb

但是，如果这只适用于旧的SVCS，那么对于关于现代Git的问题，这个答案的重点是什么？ - MestreLion

这在Git中仍然很有用，因此您可以轻松区分版本标签和其他类型的标签（标签在许多其他方面也很有用）。 - Benja

Answer 4

我不知道有没有这个功能。
但是Git不允许同时存在同名的标签和分支，所以如果你有一个名为"1.1"的分支用于1.1的工作，请不要创建一个名为"1.1"的标签，可以使用"v1.1"代替。

- VonC

---

请使用 1.1.x 分支。 - vitalii

好的，谢谢。 - y o

Answer 5

我不知道是否有任何标准。我只是选择我的标签名称，以便我可以放置一个

VERSION = `git describe --tags`

在我的构建脚本中，因此标签命名约定实际上取决于项目的版本命名约定。

- Jörg W Mittag

Answer 6

新的包管理器建议版本标签不要使用前缀v（比如PHP项目中的composer）。SemVer 2.0 没有关于标签规范的内容，这是有意为之以避免冲突。然而，在文档和文本引用中建议添加前缀v。例如，格式v1.0.4代替完整的version 1.0.4或ver. 1.0.4在文档中足够清晰优雅。

- vitalii

---

“建议……”，由谁提出的，我们在哪里可以看到原始上下文中的建议？ - bignose

@bignose 看看packagist或maven central如何解析git仓库。最好的方式是只使用数字，但是在v1.xx中'v'会被去掉。我相信还有很多其他的包括debian/ubuntu。Packagist曾经发表过一篇文章，他们更喜欢在git中使用数字标签，在文档中加上'v'前缀，但是我现在找不到了。 - vitalii

Packagist曾经发表过一篇文章，他们更喜欢在git中使用数字标签和在文档中加上前缀“v”[...]。所以这只是对那些项目的偏好，似乎没有必要太在意。 - bignose

Answer 7

我们使用分支和标签来进行与特定发布相关的工作，然后分别进行实际发布：

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

每个开发者都会在心里决定他们即将提交的工作是仅适用于主分支(master)还是也适用于其它分支。你可以看到，对分支所做的更改会合并回主分支(master)，但是一些在主分支(master)上的更改永远不会进入分支(例如，在这个例子中没有意图应用于1.6版本的更改)。

当准备发布时，我们会打标签(tag)，然后进行最后一次合并，用与分支相同的名称命名标签，但带有关于具体版本的额外标识符，例如“1.6-release”或“1.6-beta”或“1.6-rc2”等。

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

- John Feminella

---

谢谢 - 这是一个很好的回答，描述了如何进行分支，但我实际上只是想知道在git中使用某种特定（技术）命名方案是否有一些具体的原因。不过，我仍然会给你点赞，因为图表很漂亮 ;) - troelskn

啊，我明白了！很抱歉之前误解了你的问题。除了人类交流之外，没有特定的技术原因需要使用特定的名称。你可以随意为你的分支和标签命名。 - John Feminella

你的release-1.6分支叫做“1.6分支”？我以为分支名称不支持空格。 - Cees Timmerman

Answer 8

我不知道有什么最佳实践。这里是一些链接：

• http://web.elctech.com/?p=79
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html#production-tagging

一般来说，版本控制（0.0.1，v0.2.1等）可能与问题跟踪相结合被认为是一个可行的方法。（尽管我通常使用以v开头的标签名称，参见@VonC的回答）

- miku