Question

我见过很多项目使用v1.2.3作为git中标记的命名约定。我也看到了一些使用1.2.3。是否有正式认可的风格，或者是否有任何好的论据可以使用？

Answer 1

由GitHub成名的Tom Preston-Werner撰写的Semantic Versioning版本1.0.0，a sub-specification解决了这个问题：

标记规范（SemVerTag）

如果您使用版本控制系统（Git，Mercurial，则应该使用此子规范）   SVN等）来存储你的代码。使用此系统允许自动化工具检查您的   打包并确定SemVer合规性和已发布的版本。


在版本控制系统中标记版本时，版本的标记必须是   “vX.Y.Z”例如“V3.1.0”即可。

然而，在discussion删除后，the latest version of the SemVer spec（写作时为2.0.0）不再存在A later discussion thread in the same place。 Is "v1.2.3" a semantic version?进一步深入，并在SemVer master分支的常见问题解答中产生了added still not present，尽管在撰写本文时（2年后）在官方发布的规范中，此更改为{{3}}。

Answer 2

似乎有两种主导惯例（假设您还遵守一些合理的标准来自行编号）：

v1.2.3
1.2.3

v1.2.3的优点是Git文档（以及Mercurial文档）在其示例中使用了该格式，并且有几个“权限”，例如Linux kernel和Git本身使用它。（上面提到的Semantic Versioning曾经使用它，但现在不再使用它了。）

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

我认为巩固这些职位可能为时已晚。一如既往，保持一致并有意义。

更新：如this评论中所述，GitHub现在提供了一个tarball名称，其中'v'被剥离了标记。

Answer 3

前面的＆＃39; v＆＃39;是历史的。较旧的SCCS（cvs，rcs）无法区分标签标识符和修订号。标签标识符被限制为不以数字值开头，因此可以检测到修订号。

Answer 4

不是我知道的。
但Git不允许同时使用同名的标记和分支，因此如果1.1的分支“1.1”有效，请不要添加标记“{{1} }“，例如使用”1.1“

Answer 5

新的软件包管理员建议标记版本不带前缀v（对于PHP项目，如composer）。 SemVer 2.0对标签规范一无所知。这是故意做的，因为避免了冲突。但是建议在文档和文本引用中添加前缀v。例如，格式v1.0.4而不是完整version 1.0.4或ver. 1.0.4在文档中足够冗长和优雅。

Answer 6

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

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

每个开发人员都会做出精神决定，决定他们即将提交的工作是否仅适用于掌握，或者是否与分支相关。您可以看到对分支所做的更改将在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

Answer 7

我不知道有什么标准。我只是选择我的标签名称，以便我可以坚持

VERSION = `git describe --tags`

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

Answer 8

我知道没有一个最佳做法。以下是一些链接：

通常情况下，版本控制（0.0.1，v0.2.1，...）可能与某些问题跟踪同时进行，这可能被认为是合理的方法。（..虽然我通常使用v - 前缀标签名称..另见@VonC答案）

git标签有标准的命名约定吗？

8 个答案: