在对新克隆进行硬重置后，Git无法在没有冲突的情况下进行拉取

在遇到这个问题后，我对Git的运作方式提出了质疑。我对一个项目进行了一个新的

git克隆

，并将

cd

放入新创建的目录中。然后运行

git reset--hard 4.0.0

，其中

4.0.0

是附加到提交的标记。然后我运行

git pull

。。。和接收合并冲突错误？没有任何本地更改，因为我只是克隆了这个项目。修复这些冲突没有问题，但我想不出为什么Git会遇到这样的问题，在重置之后，我的本地版本基本上只是缺少远程存储库上最新的

n

提交，我想把它们拉进来。

Git pull将尝试合并默认的上游头（因此，在git重置之前的提交——默认分支的当前头）位于本地提交（即4.0.0标记）之上。获取冲突意味着4.0.0不是（旧/上游）头的祖先；它位于其他分支上，您现在正试图合并到它上

执行

git show branch 4.0.0 upstream/main

（假设上游名为

upstream

——它可能是

origin

，默认分支名为

main

）将向您显示每个分支上返回到一个通用祖先的提交

---

如果你（认为你）在回购协议中只有一个分支，那么这很可能发生在一些历史重写的混乱中——重定顺序以重新排序或合并提交或诸如此类——这使得4.0.0标记不再出现在主历史上。

标记

4.0.0

是“同一分支”的一部分吗你正在重置？我打赌它不是。所以这不仅仅是一个取消

n

提交并将其重新启动的问题。不管怎样，这一小动作的目的应该是什么？@matt，是的，远程Github上只有一个分支，但如果重置为一个标记，然后再重置为pu，到底会实现什么呢林？这就是我要问你的。“出于某些原因，对旧版本进行硬重置以测试某些东西是有帮助的”我无法想象这些原因是什么。测试旧版本的方法不是重置为提交，而是签出该提交。为什么不执行

git checkout 4.0.0

？我可能会感到困惑，但我认为这是不正确的？在远程Github存储库中，我只克隆了一个分支。本质上，我希望这是最终的目标事实的来源，因此我完全清除并在本地重新克隆该项目。如果4.0.0不是上游头的祖先，那么我肯定不能重置为它，因为我克隆它时它不在那里？当你克隆回购协议时，你会得到回购协议中的所有标签和分支，而不仅仅是你克隆的分支。但其中仍然只有一个分支所以所有克隆的标记都必须存在于该分支中，对吗？不，标记可以在任何提交上——提交不需要在任何分支上。