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

Question

我已经看到很多项目v1.2.3用作git中标签的命名约定.我也看到了一些用途1.2.3.是否有正式认可的风格,还是有任何好的论据可以使用？

Answer 1

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

标记规范(SemVerTag)

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

1. 在版本控制系统中标记版本时,版本的标记必须是"vX.YZ",例如"v3.1.0".

但是,在讨论之后,这被删除了,并且不再出现在最新版本的SemVer规范中(编写本文时为2.0.0). 后来在同一个地方的讨论主题进一步深入,并导致一个新的"v1.2.3"是一个语义版本？被添加到SemVer master分支机构的常见问题解答中,虽然在撰写本文时(2年后),这一变化仍未在官方发布的规范中出现.

Answer 2

似乎有两个主导惯例(假设您还遵守一些合理的标准来自行编号):

• v1.2.3
• 1.2.3

优点v1.2.3是Git文档(以及Mercurial文档)在其示例中使用了该格式,并且诸如Linux内核和Git之类的几个"权限" 使用它.(上面提到的Semantic Versioning使用它但不再使用它.)

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

我认为巩固这些立场可能为时已晚.一如既往,保持一致并有意义.

更新:正如本评论中所提到的,GitHub现在提供了一个tarball名称,其中"v"被剥离了标记.

Answer 3

前面的'v'的原因是历史的.较旧的SCCS(cvs,rcs)无法区分标签标识符和修订号.标记标识符被限制为不以数字值开头,因此可以检测到修订号.

Answer 4

从来没听说过.
但是Git不允许同时使用同名的标签和分支,所以如果你有一个分支" 1.1"用于1.1工作,不要放一个标签" 1.1",用于例如" v1.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`

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