当我使用Git时，我遇到了这个错误：
解析修订版时出错： e4fff73d6f29a243af63ef0a1a2bff1054d1d2ca 警告引用名称“开发”不明确。
我使用了git show-ref命令，它给了我一个存储库提交列表。我发现我有这个：
e4fff73d6f29a243af63ef0a1a2bff1054d1d2ca refs/tags/develop
e4fff73d6f29a243af63ef0a1a2bff1054d1d2ca refs/tags/origin
看来我确实有两个具有相同哈希值的提交。此外，只是为了增加混乱，在当前的Git存储库中有一个名为 develop 的分支。
我的问题是：
我如何合并，删除或只是明确解决这个问题，以便我不再让Git警告我有关含糊不清的引用？
答案 0 :(得分：3)
如评论中所述，只有一个提交具有该ID;但是该提交有多个名称（这是允许的，在某些情况下甚至是正常的，尽管不是这个特定的名称）。
错误消息似乎来自gitk（这是唯一一个包含文字字符串Error parsing revisions:的git源代码），如果是，则是由于警告消息-gitk假定任何警告消息必须是实际错误，即使这只是一个警告。
警告的关键在于：
只是为了增加混乱，有一个叫做 develop 的分支......
这意味着，未加修饰的名称develop可能表示标记 develop或分支 develop。 Git警告你，你会得到一个，而你可能意味着另一个。根据{{3}}，在这种特殊情况下，您会获得标记（但是，对于显式git checkout命令来说，这是不正确的，出于正当理由，它有自己的不同规则来决定是否将名称视为分支名称。）
警告的解决方法很简单：决定是否应该是标签（如果是，重命名或删除分支名称）或分支（如果是，重命名或删除标签名称）。最有可能的是，分支名称是正确的，标签是错误的，所以＆＃34;只是＆＃34;重命名或删除标签。
固化更改标记名称的问题是git通常假定标记名称是永久性的和全局的。如果您正在使用共享存储库，则可能会从其他人那里获取标记名称。如果您重命名或删除您的标签，您可能会再次从他们那里拿起标签，就像某种触摸传播疾病一样。要正确修复它，你必须 1 ＆＃34; cure＆＃34;您自己的存储库和您fetch的任何存储库。如果这是其他用于fetch和push操作的中央服务器存储库，您可能也必须对其进行治疗，如果它已经接收并分发了疾病＆＃34;对于其他开发者，您可能需要让他们“治愈”＃34;他们的存储库。
这真正归结为向所有开发者发送的广播电子邮件：＆＃34; oops，抱歉，存储库中的错误标记，请重命名或删除＆＃34; （也许可以在服务器上修复它，某人必须在那里修复它，但可能是有更好访问权限的人，甚至可能放入预接收或更新挂钩以拒绝尝试＆＃34;重新感染＆＃34;服务器）。
1 这个词＆＃34;必须＆＃34;实际上有点太强了。 Git不会获取所有代码，除非您将其告知（例如git fetch --tags或者使用.git/config文件。默认情况下，它会在带来标记指向的提交的同时带来标记。因此，只要您已经拥有648cc593ebe85617cc7dda6b0c126dbbf020a230，您的git就不会觉得需要重新创建标记develop。同样，git push除非有指示，否则不会推送标签。
尽管如此，如果你有伪造标签，那么其他人也可能会这样做，除非你当然是那个创造它的人。因此，与某些疾病一样，与您的伴侣进行跟进往往是明智的。