git标签有标准的命名约定吗？[关闭]

229

我已经看到很多项目v1.2.3用作git中标签的命名约定。我也看到了一些用处1.2.3。是否有正式认可的风格，或者有使用它们的任何良好论据？

git  git-tag 
— Troelskn
source
19
通过43次投票并计数，我想知道这个非常有价值的问题是否可以重新措词和重新开放，并给出一些答案，将所有要点汇总成一个很好的摘要并排在首位？@PeterEisentraut的似乎是最完整的；而可接受的答案ATM似乎有点误导。 （在阅读所​​有要点之后，我想我将自己使用v1.2.3进行标记。）
— HostileFork说不要相信2014年
1
SO是用于固定代码。最佳做法似乎属于softwareengineering.stackexchange.com或codereview.stackexchange.com
— Cees Timmerman
看看semver.org（语义版本控制），应该会给您一些想法。
— 冯布兰德
我的经验告诉我使用略有不同的方案。1.子目录：Git标签至少应v/以此名称空间中的标签分组开始。2.理想情况下，标签还应该包含唯一标识应用程序的首字母缩写词。例如v/myapp/1.0。这使git仓库的合并更加容易：如果应用程序将被合并，则标签不会在标签名称空间中发生冲突。
— AXD

Answers:

166

GitHub著名的Tom Preston-Werner 撰写的Semantic Versioning 1.0.0 版本有一个子规范可以解决这个问题：

标记规范（SemVerTag）

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

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

但是，在讨论之后，此内容已被删除，并且不再存在于最新版本的SemVer规范中（在撰写本文时为2.0.0）。 后来在同一地方进行的讨论更加深入，并产生了新的“ v1.2.3”是否是语义版本？被添加到SemVer master分支机构的FAQ中，尽管在撰写本文时（超过2年），此更改仍未出现在正式发布的规范中。

— 腹肌
source
9
谢谢-非常接近。我希望他能有合格的，为什么在v应该在那里，虽然。
— troelskn 2010年
3
@troelskn @mojombo ==汤姆·普雷斯顿-维尔纳
— 百日咳，2010年
4
— Josh Lee
41
语义版本1.0.0使用格式“ v1.2.3”。语义版本2.0.0-rc.1可能使用格式“ 1.2.3”。标记规范（SemVerTag）文章已从规范中删除。更多信息：semver.org
— petrnohejl 2013年
9
当存在旧版本（1.0版）时，将完成此答案。如今，前缀“ v”已从semver v2.0中删除。有关详细信息，请参见下面的帖子。
— vitalii，2015年
111

似乎有两个主要的约定（假设您还为发行版本本身遵守一些合理的标准）：

  • v1.2.3
  • 1.2.3

的优点v1.2.3在于，Git文档（以及Mercurial文档）在其示例中使用该格式，并且多个“权威”（例如Linux内核和Git本身）也使用它。（提到的语义版本控制曾经使用它，但现在不再使用。）

的优点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现在提供了一个tarball名称，其中标记中去除了“ v”。

— 彼得·艾森特劳特
source
13
关于GitHub和tarball生成：不再相关。他们从标签上去除了“ v”。
— 赫尔曼·比尔
6
在按字母顺序对标签进行排序时，前缀“ v”也非常有用。其他标签也可能存在。无论是正式存储在主存储库中还是本地跟踪开发人员的工作。带有'v'前缀的发布标签形成它们自己的组，而不是分散在命名空间的其余部分。
— 罗比·巴萨克
1
更新了答案以反映SemVer不再使用v。
— 亚当·斯皮尔斯
80

前面的“ v”的原因是历史性的。较旧的SCCS（cvs，rcs）无法区分标签标识符和修订号。标记标识符被限制为不能以数字开头，以便可以检测到修订号。

— 比尔·门
source
5
+1：好的第一个答案和我最喜欢的书之一的名字:-)不过，也许您的下一个答案是关于一个最新的问题。
— Johnsyweb 2011年
1
...但是如果这仅适用于较旧的 SVCS，那么对于现代Git的问题，此答案的意义是什么？
— MestreLion
3
这在git中仍然有用，因此您可以轻松地将版本标签与其他类型的标签区分开（标签对许多其他事情也很有用）
— Benja 2013年
19

从来没听说过。
但是Git不允许标签和同名分支同时使用，因此如果您有一个分支“ 1.1”用于1.1工作，则不要放置标签“ 1.1”，例如使用“ v1.1”

— 冯
source
8
用于分支1.1.x。而已。
— vitalii 2015年
1
很好，谢谢。
— RY
10

新的软件包管理器建议标记没有前缀的版本v（例如PHP项目的作曲家）。 SemVer 2.0与标签规范无关。避免冲突是有意完成的。但是，建议v在文档和文本参考中添加前缀。作为示例格式，v1.0.4而不是完整的文档，version 1.0.4或者ver. 1.0.4在文档中不够详细和优雅。

— 生命力
source
22
“建议...”由谁提供，我们可以在原始背景下从哪里看到该建议？
— bignose
8

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

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
— 约翰·费米内拉
source
谢谢-这是描述分支方式的一个很好的答案，但实际上我的意思是，如果在git中使用某些命名方案存在某些（技术上的）原因。仍然给您一个不错的图表支持；）
— troelskn 2010年
啊，该死！很抱歉误解您的问题。不，除了人际交流以外，没有使用特定名称的具体技术原因。您可以随意命名分支和标签。
— 约翰·费米内拉
您的release-1.6分支名为“ 1.6分支”吗？我以为分支名称不支持空格。
— Cees Timmerman
8

我不知道任何标准。我只需选择我的标签名称即可粘贴

VERSION = `git describe --tags`

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

— 约格·米塔格
source
1
git describe --tags：>
— Damien Carol
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.