在实际发布之后，我们分别为特定于发布的工作使用分支和标记:

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

据我所知没有。 但是Git不允许一个标签和一个同名的分支同时存在，所以如果你有一个“1.1”分支用于1.1作品，就不要放一个“1.1”标签，使用“v1.1”为例。

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

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)

在实际发布之后，我们分别为特定于发布的工作使用分支和标记:

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`

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

语义版本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年多以后)，这个变化仍然没有出现在正式发布的规范中。