很多人在处理Git标签重命名问题时，都会参考官方文档里的这段内容：

当你打错标签并想要重新打标签时该怎么做？
若从未推送过标签，直接重新打标签即可，使用"-f"参数替换旧标签，操作完成。
但如果已推送标签（或他人可直接读取你的仓库），其他人已获取旧标签，此时有两种选择：
合理做法：承认失误，使用新的标签名。由于他人已见过原标签名，若保留同名，可能出现两人持有"版本X"但实际内容不同的情况，因此可命名为"X.1"。
不合理做法：即便他人已见过旧标签，仍坚持将新版本命名为"X"，再次使用git tag -f命令，如同从未推送过旧标签。
然而，Git不会（也不应）在用户不知情的情况下修改标签。若他人已获取旧标签，执行git pull不应直接覆盖旧标签。
若他人从你处获取了发布标签，你无法仅通过更新自己的标签来修改他人的标签，这是重大安全问题，因为用户必须能够信任标签名。若执意采取不合理做法，需告知他人你的失误。

我之前也在Stack Exchange上发布过《Git retagging sane and insane advice - Part 1》的相关问题，可以作为参考。

最近我做了一个实验：我有同一个远程仓库的两个本地仓库repo1和repo2，执行了以下操作：

• 在repo1中创建名为X的附注标签；
• 将该标签推送到远程仓库；
• repo2拉取该标签；
• 在repo1中删除标签X，重新创建同名但消息不同的标签X；
• 将新标签推送到远程仓库（这里必须用git push origin -f X，因为远程已存在同名标签，正常推送会失败）；
• 在repo2中执行git pull --tags，发现标签X被更新了。

这和官方文档的描述似乎矛盾，为什么会出现这种情况？

原因解析 #

官方文档里提到的“git pull不应直接覆盖旧标签”，指的是默认的git pull行为——也就是不带--tags参数的情况。默认情况下，git pull只会获取与当前分支相关的标签，不会主动同步所有标签，更不会擅自覆盖本地已有的标签。

而你使用的git pull --tags是一个特殊操作，它等价于git fetch --tags && git merge FETCH_HEAD。其中git fetch --tags会告诉Git获取远程仓库的所有标签，这时候如果远程仓库的标签已经被强制更新（比如你在repo1用git push -f推送了新的X标签），Git的行为会根据你的配置和版本有所不同：

1. 默认行为（Git 2.0+）：正常情况下，git fetch --tags不会覆盖本地已存在的同名标签，除非你添加-f（强制）参数。如果你没有加-f却发现标签被更新了，很可能是你的Git配置中修改了默认行为——比如设置了tag.followTags=true，这个配置会让Git在fetch时自动更新与当前分支关联的标签；或者启用了fetch.pruneTags，不过这个配置主要是用来删除本地存在但远程已删除的标签。
2. 推送方式的影响：如果你在repo1推送新标签时，先删除了远程的旧标签（git push origin :X），再推送新标签，此时远程的X标签是全新创建的。有些Git版本在这种情况下，执行git fetch --tags会认为这是一个新标签，从而覆盖本地的旧标签（虽然逻辑上这并不正确，但这可能是某些版本的特殊行为）。

总结 #

官方文档的描述是基于最安全的默认操作，而git pull --tags属于主动触发全量标签同步的操作，它的行为可能会因为配置或版本差异而改变。如果想要避免本地标签被意外覆盖，建议：

• 尽量遵循官方文档的“合理做法”，使用新的标签名而非覆盖旧标签；
• 如果必须覆盖，提前告知所有仓库使用者，让他们手动执行git tag -d X && git fetch origin tag X来更新标签；
• 避免使用git pull --tags，而是按需获取特定标签，比如git fetch origin tag X。

内容的提问来源于stack exchange，提问作者Number945