为什么服务器上的标签不应该被移除？

Question

阅读Gerrit文档，它说：

[...] users should be really knowledgeable about git, 
for instance knowing why tags never should be removed from a server

这个声明并没有详细说明原因。我认为这没有问题，也找不到任何相关信息。

那么，为什么标签从服务器中不应该被删除？

- fracz

Answer 1

在http://git-scm.com/docs/git-tag的“重新打标签”章节中解释了为什么不应该删除远程标签。

简而言之: 如果协作者已经获取了标签，那么在您更改标签后，它将不会更新。因此，标签变得相当无用，因为它代表远程存储库中的提交A，但它可能代表少数开发人员存储库中的提交B。

- gturri

Answer 2

如果您点击 标注标签，它们应该代表“项目达到值得在历史上记住的稳定发布点时使用的标签”。

由于 Gerrit 中的项目所有者有权删除标签，因此文档中添加了警告，以便依赖这些标签的其他用户不会感到惊讶（或得到适当的警告），如果那个标签发生更改（或被删除）。

请参阅“强制执行站点范围访问策略”部分。

通过将refs/*的访问权限授予一个组，Gerrit管理员可以将维护该项目的访问权限的责任委派给该组。
在企业部署中，往往需要强制执行一些访问策略。例如，甚至项目所有者也不能更新或删除标签。
ALLOW和DENY规则并不足以实现此目的，因为项目所有者可以授予自己任何他们希望的访问权限，从而有效地覆盖来自“所有项目”或某个其他公共父项目的任何继承访问权限。
这就是为什么Gerrit提出：

确保没有人可以更新或删除标签

这个要求在需要保证构建的可重复性的企业部署中非常普遍。为了实现这一点，我们在“所有项目”中阻止匿名用户推送权限：

[access "refs/tags/*"]
  push = block group Anonymous Users
  create = group Project Owners
  pushTag = group Project Owners

- VonC

Answer 3

在这里，“最佳实践”是不要这样做。但也可能有一些合法的原因...

并非所有标签对于下游流程（CI/CD、发布）都很重要。（也不必为所有标签添加注释）此外，许多在发布和里程碑之间的标签通常只是一些不完整的子项目，除了文档之外几乎没有功能意义。

例如，在1.3.8.5-final（已发布）和1.3.8.6-alpha之间的开发标签可能只包含一些为了触发CI/CD并执行测试而创建的标签子集。标签1.3.8.6-feature-3343-0到1.3.8.6-feature-3343-5可能都是不完整且不稳定的。我认为删除它们没有太大的危害。

通常情况下，没有重要的理由这样做；但也可能存在一些情况，你希望消除混淆，比如开发人员创建了标签1.3.8.5-feature-3343-6，但实际上想创建的是1.3.8.6-feature-3343-6。在这种情况下，你可能希望通过删除错误来澄清代码进展的历史，并且由于该标签没有下游使用，所以不会产生重大后果。

- Rondo