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

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

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

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 answer)

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

v1.2.3 1.2.3

v1.2.3的优点是Git文档(以及Mercurial文档)在其示例中使用了这种格式，而且Linux内核和Git本身等几个“权威”都使用这种格式。(前面提到的语义版本控制曾经使用它，但现在不再使用了。)

The advantages of 1.2.3 are that gitweb or GitHub can automatically offer a tarball or zip download of the form packagename-$tag.tar.gz (and I think it's quite established that a tarball should not be named package-v1.2.3.tar.gz). Alternatively, you can use git describe directly to generate tarball version numbers. For lightweight projects without a formal release process, these possibilities can be quite convenient. It should also be noted that Semantic Versioning is by no means the only or a universally accepted standard for version numbering. And notable projects such as GNOME as well as countless other projects do use the 1.2.3 tag naming.

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

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

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

VERSION = `git describe --tags`

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

语义版本1.0.0版本，由Tom Preston-Werner的GitHub成名，有一个解决这个问题的子规范:

标签规范(SemVerTag) 如果你使用版本控制系统(Git, Mercurial， SVN等)来存储您的代码。使用这个系统可以让自动化工具检查你的 包并确定SemVer遵从性和发布版本。 当在版本控制系统中标记版本时，版本的标记必须为 “vX.Y。Z”。“v3.1.0”。

然而，经过讨论后，这一问题被删除了，并且在SemVer规范的最新版本(撰写本文时为2.0.0)中不再存在。在同一个地方，后来的讨论更深入，并产生了一个新的“v1.2.3”是语义版本吗?被添加到SemVer主分支的FAQ中，尽管在撰写本文时(2年多以后)，这个变化仍然没有出现在正式发布的规范中。