git标签有一个标准的命名约定吗？
我已经看到很多使用v1.2.3的项目作为git中标签的命名约定。 我也看到了一些使用1.2.3 。 是否有官方认可的风格，还是有什么好的理由使用？
有语义版本 ，由github的Tom Preston-Werner声誉：
标记规范 （SemVerTag）
如果你使用版本控制系统（Git，Mercurial，SVN等）存储你的代码，应该使用这个子规范。 使用这个系统允许自动化工具检查你的包并确定SemVer合规性和发布版本。
- 在版本控制系统中标记版本时，版本的标签必须是“vX.YZ”，例如“v3.1.0” 。
似乎有两个主要的惯例（假设你自己也遵守一些合理的编号发布的标准）：
-
v1.2.3 -
1.2.3
v1.2.3的好处在于，Git文档（以及Mercurial文档）在其示例中使用了这种格式，并且Linux内核 ， Git本身以及所提到的语义版本控制等几个“权威”使用它。
1.2.3的好处是，gitweb或者GitHub可以自动提供packagename-$tag.tar.gz格式的压缩包或压缩包下载（我认为tarball不应该被命名为package-v1.2.3.tar.gz ）。 或者，你可以直接使用git describe来生成tarball版本号。 对于没有正式发布过程的轻量级项目，这些可能性可能相当方便。 还应该注意的是，语义版本控制绝不是版本编号唯一或普遍接受的标准。 像GNOME这样值得注意的项目以及无数其他项目都使用1.2.3标签命名。
我认为巩固这些立场可能为时已晚。 一如既往，保持一致和有意义。
更新：正如在这个评论中所提到的，GitHub现在提供了一个tarball名字，其中的'v'被剥离掉了。
前面“v”的原因是历史的。 较旧的SCCS（cvs，rcs）无法区分标签标识符和修订版本号。 标签标识符被限制为不以数字值开头，以便可以检测到修订号。
从来没听说过。
但是Git不会同时允许一个标签和一个同名的分支，所以如果你有1.1的分支“ 1.1 ”，不要把标签“ 1.1 ”，比如“ v1.1 ”
新的包pipe理器build议不用前缀v来标记版本（就像PHP项目的composer php一样）。 SemVer 2.0与标签规格没有任何关系。 这是有意避免冲突。 不过， build议在文档和文本引用中添加前缀v 。 作为例子格式v1.0.4而不是完整version 1.0.4或version 1.0.4 ver. 1.0.4 在文档中ver. 1.0.4是足够冗长和优雅的。
我们使用分支和标签分别进行特定于发行版的工作，然后分别使用实际版本：
o---o-----o---o---o--- ... master \ / / \ / / o-------o--- ... 1.6 branch
每个开发人员都会对他们即将提交的工作是否适用于主人或者是否与分支有关而作出精神决定。 您可以看到，对分支所做的更改将合并到主分支上，但主分支上的某些更改永远不会分支到分支上（即，在此示例中不会用于1.6版本）。
当我们准备发布时，我们对它进行标记，然后最后一次合并，我们用与分支名称相同的名称命名该标签，但是有一个额外的标识符，例如“1.6版本”或“1.6-beta”或“1.6-rc2”等等。
... ------o---o---o--o---o--- ... master / / / / ... ---o------(*)--- ... 1.6 branch 1.6-release
我不知道有什么标准。 我只是select我的标签名称，使我可以坚持一个
VERSION = `git describe --tags`
在我的构build脚本。 所以，标签命名约定实际上取决于项目的版本命名约定。
没有人知道我的最佳做法。 这里有一些链接：
- 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答案）
