我使用Atlassian BitBucket作为我的远程git服务器。我有一个从远程克隆的本地git仓库。当终端的活动文件夹是仓库的顶层文件夹（即包含.git子文件夹的文件夹）时，在终端中执行以下命令。
我首先使用以下命令查询本地存储库的状态。
git状态
结果如下。
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean然后我创建了一个带注解的标记，如下所示：
git标签-a MyTag-m "这是一个标签。"
我在本地存储库中查询了它的标记列表，如下所示：
git标签
结果如下。
MyTag然后我执行了push，因此：
git推送
结果如下。
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 205 bytes | 205.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
To bitbucket.org:User/RemoteRepository.git
* [new tag] MyTag -> MyTag然后，我查询遥控器的标签列表，如下所示：
git ls-远程--标记源
结果输出如下所示（为了简洁起见，我删除了下面清单中的大部分哈希数）。
4c...d8 refs/tags/MyTag
fa...a2 refs/tags/MyTag^{}应该注意的是，在执行上述过程之前，我从未向存储库添加过标记。
- 问题**
push操作的输出似乎表明标签被推送到遥控器，但是push命令既不包含选项--tags也不包含选项--follow-tags。那么，为什么push操作要将标签MyTag推送到遥控器？它实际上推了标签吗？
1.从遥控器中检索到标签列表后，标签列表中包含了我没有创建的标签，即MyTag^{}。为什么？每当标签X被推送时，标签X^{}总是自动添加到遥控器中吗？有没有办法避免这种行为，并且只推送显式创建的标签？
1条答案
按热度按时间xiozqbni1#
push操作的输出似乎表明标签被推送到遥控器，但是push命令既不包含选项--tags也不包含选项--follow-tags。那么，为什么push操作将标签MyTag推送到遥控器？它实际上推了标签吗？是的，原因很简单：
--follow-tags默认为 true，如果您没有另外配置它。如果您已经配置它默认为false，则命令行上的显式--follow-tags将覆盖;如果没有-如果您已经将其配置为true或默认为true-命令行上的explcit--no-follow-tags将覆盖。1....正在从远程[显示]
MyTag^{}检索标记列表...这是正常的：
MyTag^{}* 本身 * 不是标记，而是MyTag是一个 * annoted * 标记这一事实的产物，它本身就是一个对象。使
git fetch成为自己的--follow-tags（这也是默认设置）工作时，Git需要知道哪些标签（如果有的话）直接指向任何特定对象（通常是任何特定的提交）。Git通过哈希ID“知道”对象。在--follow-tags下，如果你的git fetch带出了发送方refs/tags/T所指向的对象，那么你自己的（接收方）git fetch操作应该会创建refs/tags/T。但是你的Git软件怎么知道那是哪个对象呢？为了回答这个问题，sending Git软件不仅要发送标签名称和对应的哈希ID，而且还要发送这个标签的 target，如果 * 这个标签是一个带注解的标签。（如果不是，则标记名直接指向对象，而不是指向对象的注解标记，因此不需要额外的步骤。）由于Git已经有了一个语法，表示“如果引用是带注解的标签，则跟随标签到达其目标”，传输协议（用于获取和推送）简单地借用了这个现有语法。
该语法是将
^{}添加到引用中，这就是您在这里看到的内容。