我已将buildroot git存储库（https://git.buildroot.net/buildroot）克隆到运行Debian Stretch的主机开发机器上的本地存储库中。
一切都很好，git remote -v的输出是：
origin https://git.buildroot.net/buildroot（fetch）
origin https://git.buildroot.net/buildroot（推送）
现在我使用git tag列出repo标签，并想要检查最后一个标签（目前是2018.02）并同时创建本地分支。
如果我使用git checkout -b 2018.02 2018.02它可以正常工作，但如果我使用git checkout --track origin/2018.02则会失败：
致命：无法更新路径并切换到分支机构＆＃39; 2018.02＆＃39;在同一个 时间。您打算结账＆2019.02＆＃39;哪个不可以 解决了提交？
如何解决此错误？
注意：我的git版本是2.11.0。
谢谢。
答案 0 :(得分：4)
使用git checkout -b 2018.02 2018.02确实有用，原因可能是你没想到的。
首先，阅读the gitrevisions documentation，其中描述了Git将名称转换为提交哈希的正常过程：
＆lt; refname＆gt; ，例如 master ， heads / master ， refs / heads / master < / p>
符号引用名称。 ......当含糊不清时，通过采用以下规则中的第一个匹配来消除＆lt; refname＆gt; 的歧义：
（然后它列出了六个规则步骤）。在你的情况下，你给Git的名字是2018.02（作为git checkout的最后一个参数），当匹配的唯一引用名是refs/tags/2018.02时 - 分支名称refs/heads/2018.02不存在（尚未！）。
因此，Git解析标记，最终找到提交哈希标识8a94ff12d232ada68cff5957089a78a1f0b8f192，并检查该提交。当它这样做时，创建一个名为2018.02的分支，以便在git checkout完成后，refs/heads/2018.02 也存在。< / p>
现在有一个问题：引用名称不明确。 2018.02是否代表标记名称 2018.02？或者它是否意味着分支名称？
再次阅读同一个句子，即六个步骤之前的句子：
...当含糊不清时，＆lt; refname＆gt; 会通过以下规则中的第一场比赛来消除歧义：
第一次匹配是在名称前添加refs/tags/的匹配，因此大多数命令（{1}}都会仍然无论您的分支名称发生什么，都可以参考提交2018.02。
8a94ff12d232ada68cff5957089a78a1f0b8f192命令不遵循以下六个步骤：如果您说git checkout，则Git首先查看git checkout 2018.02的。如果存在，Git会检出分支名称，方法是将refs/heads/2018.02附加到HEAD并检查该名称标识的提交。如果您在创建分支名称后进行了一些新的提交，那么这将是其他一些提交 - 而不是refs/heads/2018.02。
大多数其他Git命令将找到标记名称。再补充一句话并考虑：
如果你碰巧同时拥有 head / master 和标签/ master ，你可以明确地说 heads / master 告诉Git哪一个你的意思是。
这也适用于您的姓名8a94ff12d232ada68cff5957089a78a1f0b8f192：您可以写出2018.02表示标记名称，tags/2018.02表示分支名称。但是，最好不要首先考虑这种情况：选择其他一些分支名称并且根本不存在歧义。