git标签是否有一个标准的命名约定?

小开

据我所知没有但是Git不允许标签和同名的分支同时存在，所以如果你有一个分支"1.1"用于1.1工作，不要放一个标签"1.1"，使用例如"v1.1"

小开

据我所知，没有一个最佳实践。以下是一些链接:

一般来说，版本控制(0.0.1， v0.2.1，…)可能与一些问题跟踪一起被认为是一种合理的方法。(. .虽然我通常使用__abc2前缀标记名..参见@VonC answer)

小开

在实际发布之后，我们分别为特定于发布的工作使用分支和标记:

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

每个开发人员都会在心里做出决定，决定他们即将提交的工作是否只适用于master，或者是否也与分支相关。您可以看到，对分支所做的更改被合并回master上，但是master上的一些更改永远不会在分支上进行(也就是说，在本例中，这些更改不是针对1.6发行版的)。

当我们准备好发布时，我们标记它，然后最后一次合并回来，我们用与分支相同的名称命名标记，但是有一个关于它是什么特定版本的额外标识符，例如。“1.6-release”或“1.6-beta”或“1.6-rc2”等等。

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

小开

我不知道有什么标准。我只是选择我的标记名称，这样我就可以粘贴

VERSION = `git describe --tags`

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

小开

最佳答案

语义版本控制的1.0.0版本，由Tom Preston-Werner的GitHub成名，有一个sub-specification解决这个问题:

标签规格 (SemVerTag)
如果你使用版本控制系统(Git, Mercurial， SVN等)来存储您的代码。使用这个系统可以让自动化工具检查你的
. package并确定SemVer的遵从性和发布版本

当在版本控制系统中标记发布时，版本的标记必须是 “vX.Y.Z"例如“v3.1.0" > < /强劲。李< / >

在讨论之后，然而被删除，并且在SemVer规范的最新版本(撰写本文时为2.0.0)中不再存在。稍后在同一地方的讨论线程进行了更深入的研究，并在SemVer的master分支的FAQ中产生了一个新的是“v1.2.3"语义版本?为添加，尽管在撰写本文时(超过2年后)，这个更改在正式发布的规范中是仍然没有出现。

小开

似乎有两个主要的惯例(假设你也遵守一些合理的标准来编号版本本身):

v1.2.3

1.2.3

v1.2.3的优点是Git文档(以及Mercurial文档)在其示例中使用该格式，并且一些“权威”，如Linux内核和Git本身使用它。(前面提到的语义版本控制< em > < / em >曾经使用它，但不再使用了。)

1.2.3的优点是gitweb或GitHub可以自动提供格式为packagename-$tag.tar.gz的tarball或zip下载(而且我认为tarball应该被命名为不是非常确定的)。或者，你可以直接使用git describe来生成tarball版本号。对于没有正式发布过程的轻量级项目，这些可能性非常方便。还应该注意的是，语义版本控制绝不是版本编号的唯一或被普遍接受的标准。著名的项目，如GNOME以及无数其他项目确实使用1.2.3标记命名。

我认为现在巩固这些地位可能为时已晚。一如既往，保持一致，讲得通。

更新:正如这评论中提到的，GitHub现在提供了一个带“v”标签的tarball名称。

小开

前面的“v”有历史原因。旧的SCCS (cvs、rcs)无法区分标记标识符和修订号。标记标识符被限制为不以数值开头，以便可以检测到修订号。

小开

新的包管理器建议标记版本没有前缀v(如PHP项目的作曲家)。 SemVer 2.0没有标签规范。这是为了避免冲突而故意做的。然而，在文档和文本引用中添加前缀v是建议。作为例子，格式v1.0.4代替完整的version 1.0.4或ver. 1.0.4在文档中足够冗长和优雅