在git标签名称中添加“/”以创建分层/嵌套标签会出现问题吗？

Question

我们在git仓库中创建了一个名为"2012/02/16"的标签。然后我们发现，在Source Tree中，2012和01被表示为可以整齐地打开和关闭以显示和隐藏标签的文件夹。拥有嵌套层次结构的标签似乎是一种很好的组织标签的方式，而不仅仅是拥有一个平面列表。
这样做是否存在问题？
当我运行git ls-remote命令时，我看到以下条目：

8430572c89362b875109628c33a18e782aa38488    refs/tags/2012/02/16
d247e38159c8c4998bf8b555edfd7ffe7b945255    refs/tags/2012/02/16^{}

我不确定第二个标签末尾的^{}字符是什么意思，我想确保我们碰巧发现的这种行为不是我们在清理标签之前应该做的事情，

我们在“非嵌套”标签上看不到^{}字符。

- cclark

---

^{}是一个简写语法，用于递归取消标签的引用，直到找到一个非标签对象为止。如果您在其他标签上没有看到它，则可能意味着您的其他标签是轻量级标签而不是已注释的标签。 - Lily Ballard

Answer 1

你会遇到的唯一问题是如果你试图创建一个与你的层次结构中的“目录”发生冲突的标签，你将会收到一条不太有用的错误消息（这是由git用于存储标签的目录直接导致的冲突）：

% git tag foo/bar
% git tag foo
error: there are still refs under 'refs/tags/foo'
fatal: refs/tags/foo: cannot lock the ref

这在实践中不太可能成为问题，通常会在人们尝试执行以下操作时出现:

v0.0.1/rc1
v0.0.1/rc2
v0.0.1/beta1
v0.0.1/beta2

然后，尝试打标签v0.0.1，这将遇到上述问题。

- FauxFaux

---

非常感谢！我有一个标记为“1.3.39/40”的提交，试图将其分别重新标记为1.3.39和1.3.40，因此我键入了git tag 1.3.39 -am“版本1.3修订39”1.3.39/40并收到了此错误。只需删除带斜杠的标记，然后通过提供提交哈希添加新标记即可解决问题。 - Dan Bechard

Answer 2

没问题，使用斜杠是标准惯例，例如在“git-flow”学科中。您可以在手册页面git-check-ref-format（1）中查看标记名称的语法规则： https://git-scm.com/docs/git-check-ref-format 带括号的插入符是git试图告诉您有关该标记的信息，而不是您输入的内容。您可以使用手册页gitrevisions（7）进行解释： https://git-scm.com/docs/gitrevisions

- minopret

---

對樓主的說明：使用斜線是完全沒問題的，你可以把它視為巢狀結構，但是實際上，git命令不會將您的標籤集視為層次結構。這只是它們存儲的方式。 - Cascabel

Answer 3

除了文件/目录冲突问题，还有一个大小写敏感的问题可能会出现。如果你在像Windows和Mac OS X这样的不区分大小写的文件系统上运行，则可能无法获取/拉取远程存储库上的标签。例如，以下内容将发生冲突：

archive/some-tag-or-other
Archive/a-different-tag

当Git创建第二个标签时，它实际上被放置在.git/refs/tags/archive目录中。一旦处于这种状态，随后的获取/拉取将不断尝试重新获取第二个标签。

然而，有一个简单的解决方法，就是运行git pack-refs，它将各个ref文件合并到纯文本文件.git/packed-refs中。一旦运行它，第一个标签的单独标签文件将被删除，以及.git/refs/tags/archive目录，然后才能成功获取/拉取第二个标签。

- markshep

---

与问题无关。标签 Some-tag 和 some-tag 会导致相同的结果，而不涉及任何文件夹。 - Chronial