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

Is there a standard naming convention for git tags?

提问by troelskn

I've seen a lot of projects using v1.2.3as the naming convention for tags in git. I've also seen some use 1.2.3. Is there an officially endorsed style, or are there any good arguments for using either?

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

采纳答案by peritus

Version 1.0.0 of Semantic Versioning, by Tom Preston-Werner of GitHub fame, had a sub-specificationaddressing this:

由 GitHub 名人 Tom Preston-Werner编写的Semantic Versioning1.0.0版本有一个子规范来解决这个问题：

Tagging Specification(SemVerTag)

This sub-specification SHOULD be used if you use a version control system (Git, Mercurial, SVN, etc) to store your code. Using this system allows automated tools to inspect your package and determine SemVer compliance and released versions.

1. When tagging releases in a version control system, the tag for a version MUST be "vX.Y.Z" e.g. "v3.1.0".

标记规范(SemVerTag)

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

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

However, after discussionthis was removed, and is no longer present in the latest version of the SemVer spec(2.0.0 at the time of writing). A later discussion thread in the same placewent into greater depth, and resulted in a new Is "v1.2.3" a semantic version?being addedto the FAQ in SemVer's masterbranch, although at the time of writing (over 2 years later) this change is still not presentin the officially released spec.

但是，经过讨论后，它被删除了，并且不再出现在SemVer 规范的最新版本中（在撰写本文时为 2.0.0）。 后来在同一个地方的一个讨论线程更深入，并产生了一个新的“v1.2.3”是一个语义版本吗？被添加到 SemVermaster分支的常见问题解答中，尽管在撰写本文时（2 年多后），此更改仍未出现在正式发布的规范中。

回答by Peter Eisentraut

There appear to be two dominating conventions (assuming you also abide by some reasonable standard for numbering the releases themselves):

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

• v1.2.3
• 1.2.3

• v1.2.3
• 1.2.3

The advantages of v1.2.3are that the Git documentation (and also the Mercurial documentation) uses that format in its examples, and that several "authorities" such as the Linux kerneland Gititself use it. (The mentioned Semantic Versioningused to use it but doesn't any more.)

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

The advantages of 1.2.3are that gitweb or GitHub can automatically offer a tarball or zip download of the form packagename-$tag.tar.gz(and I think it's quite established that a tarball should notbe named package-v1.2.3.tar.gz). Alternatively, you can use git describedirectly to generate tarball version numbers. For lightweight projects without a formal release process, these possibilities can be quite convenient. It should also be noted that Semantic Versioning is by no means the only or a universally accepted standard for version numbering. And notable projects such as GNOME as well as countless other projects do use the 1.2.3tag naming.

的优点1.2.3是叫做gitweb或GitHub上可以自动提供一个压缩包或压缩形式的下载packagename-$tag.tar.gz（我认为这是相当确定了一个压缩包应该不被命名package-v1.2.3.tar.gz）。或者，您可以git describe直接使用生成 tarball 版本号。对于没有正式发布流程的轻量级项目，这些可能性非常方便。还应注意的是，语义版本化绝不是唯一或普遍接受的版本编号标准。像 GNOME 这样的著名项目以及无数其他项目确实使用了1.2.3标签命名。

I think it's probably too late to consolidate these positions. As always, be consistent and make sense.

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

---

---

Update: As mentioned in thiscomment, GitHub now offers a tarball name with the 'v' stripped off of the tag.

更新：正如本评论中提到的，GitHub 现在提供了一个 tarball 名称，其中 'v' 从标签中剥离。

回答by Bill Door

The reason for the preceding 'v' is historical. Older SCCS (cvs,rcs) could not distinguish between a tag identifier and a revision number. Tag identifiers were restricted to not begin with a numeric value so that revision numbers could be detected.

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

回答by VonC

Not that I know of.
But Git will not allow a tag and a branch of the same name at the same time, so if you have a branch "1.1" for 1.1works, do not put a tag "1.1", use for instance "v1.1"

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

回答by vitalii

New package managers advice to tag versions withoutprefix v(like composerfor PHP projects). SemVer 2.0has nothing about tag specification. It's done intentionally due avoiding conflicts. However it's advisedto add prefix vin documentation and text references. As example format v1.0.4instead of full version 1.0.4or ver. 1.0.4is enough verbose and elegant in documentation.

新的包管理器建议在没有前缀的情况下标记版本v（如PHP 项目的composer）。 SemVer 2.0没有任何关于标签规范的内容。由于避免冲突，这是有意完成的。但是建议v在文档和文本参考中添加前缀。作为示例格式v1.0.4而不是完整的version 1.0.4或ver. 1.0.4在文档中足够冗长和优雅。

回答by John Feminella

We use branches and tags for release-specific work followed by the actual release, respectively:

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

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

Every developer makes a mental decision about whether the work they're about to commit is applicable just to master or if it's also relevant to the branch. You can see that changes that are made to the branch are merged back on master, but some changes on master will never go on the branch (that is, those not intended for the 1.6 release, in this example).

每个开发人员都会对他们即将提交的工作是否仅适用于 master 或者它是否也与分支相关做出心理决定。您可以看到对分支所做的更改合并回 master，但 master 上的某些更改永远不会在分支上进行（即，在此示例中，那些不打算用于 1.6 版本的更改）。

When we're ready to release, we tag it and then merge back one last time, and we name the tag with the same name as the branch, but with an extra identifier about what particular version it is, e.g. "1.6-release" or "1.6-beta" or "1.6-rc2", et cetera.

当我们准备发布时，我们标记它然后最后一次合并回来，我们用与分支相同的名称命名标记，但附加一个关于它是什么特定版本的标识符，例如“1.6-release”或“1.6-beta”或“1.6-rc2”等。

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

回答by J?rg W Mittag

I don't know of any standards. I simply choose my tag names such that I can stick a

我不知道任何标准。我只是选择我的标签名称，这样我就可以贴上

VERSION = `git describe --tags`

in my build scripts. So, the tag naming convention actually depends on the version naming convention of the project.

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

回答by miku

There is no onebest practice I'm aware of. Here are some links:

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

• http://web.elctech.com/?p=79
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html#production-tagging

• http://web.elctech.com/?p=79
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html#production-tagging

Generally, versioning (0.0.1, v0.2.1, ...) maybe hand in hand with some issue-tracking could be considered a plausible approach. (.. although I usually use v-prefixed tag names .. see also @VonC answer)

通常，版本控制 ( 0.0.1, v0.2.1, ...) 可能与一些问题跟踪一起被认为是一种可行的方法。（..虽然我通常使用带v前缀的标签名称..另见@VonC答案）