一位朋友做了一个“git reset --hard origin”，然后推送了他的更改。他这样做了，而不是去“git reset --hard origin/branch_name”，这是他真正想要的。
我认为所有“git reset --hard origin”所做的都是重置您的分支以完全匹配所有相关的远程分支。然而，在他推动之后，我做了一个“git pull origin branch_name”，出于某种未知的原因，一堆似乎来自 master 的新文件被拉了出来（就像 master 的合并一样）；但是在本地和远程日志中，我们从来没有看到这些文件被提交或从 master 到我们的分支的任何合并，我们只知道问题发生在那个 push 之后并且不知道实际发生了什么。
似乎将当前分支重置为默认（即通常是主）分支的状态origin。
这是一个有趣的问题......gitrevisions手册页正式涵盖了这一点（<refname>案例，第 5 点），但没有说明如果以<refname>这种方式解决 a 究竟会发生什么。
我试图这样做git rev-parse origin，Git 告诉我这个修订是模棱两可的（即未找到），而且我refs/remotes/origin在用于测试的 repo 中确实有。
在启用了命令执行跟踪（在环境中）的情况下尝试git reset --hard origin在同一个 repo中解决.GIT_TRACE=1git rev-parse
因此，我对此的看法是，您的同事（据说是错误的）有一个真正的本地分支或名为“origin”的标签，因此git reset --hard origin实际上将他们当前签出的分支重置为该本地分支“origin”的尖端提交。
我现在将通过运行git branch -a并git tag在他们的 repo 中检查这个假设。