git标记有标准的命名约定吗?[关闭]

版本1.0.0 Semantic Versioning ,作者是Github名人的Tom Preston Werner, a sub-specification 解决这个问题:

标签规范 (SimVelTAG)

如果您使用版本控制系统(Git、Mercurial和 SVN等)存储代码。使用此系统允许自动工具检查 打包并确定semver的符合性和发布版本。

1. 在版本控制系统中标记版本时, 版本的标记必须是 “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? 存在 added Semver的常见问题解答 master 尽管在撰写本文时(2年后),这种变化是 still not present 在正式发布的规范中。

似乎有两个主要的约定(假设您也遵守一些合理的标准来对发行版本身进行编号):

• v1.2.3
• 1.2.3

的优点 V1.2.3 git文档(以及mercurial文档)是否在其示例中使用了这种格式,以及诸如 Linux kernel 和 Git 自己使用它。(上述 Semantic Versioning 曾经用过但现在不用了。)

的优点 1.2.3 gitweb或github是否可以自动提供tarball或zip格式的表单下载 packagename-$tag.tar.gz (我认为已经很确定的是柏油球应该 不 被命名 package-v1.2.3.tar.gz )或者,您可以使用 git describe 直接生成tarball版本号。对于没有正式发布过程的轻量级项目,这些可能性非常方便。还应注意的是,语义版本控制决不是唯一或普遍接受的版本编号标准。像GNOME这样著名的项目以及无数其他项目都使用 1.2.3 标签命名。

我认为巩固这些职位可能已经太迟了。一如既往,保持一致,讲道理。

更新:如中所述 this 注释,github现在提供了一个tarball名称,去掉了标签上的“v”。

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

我不知道。
但是git不允许标记和同名分支同时出现,所以如果您有一个分支” 1.1 “为了 一点一 好的,不要贴标签” 一点一 ,例如使用 v1.1 “

新的包管理器对标记版本的建议 没有 前缀 v (像 composer 对于php项目)。 SemVer 2.0 对标记规范没有任何要求。这是为了避免冲突而故意做的。然而,它是 细想过的 添加前缀 V 在文档和文本引用中。作为示例格式 v1.0.4 不是满的 version 1.0.4 或 ver. 1.0.4 在文档中足够详细和优雅。

我们使用分支和标记分别执行特定于发布的工作和实际发布:

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`

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

没有 一 我知道的最佳实践。以下是一些链接:

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