我已经通过移动到commit_sha来修复它，最后提交给origin/master。

git reset --hard commit_sha

警告:在commit 'commit_sha' commit之后，你将丢失所有提交的内容。

在我的例子中，这里是我所做的导致分歧的消息:我做了git push，但后来做了git commit——amend，以向commit消息中添加一些东西。然后我又做了另一次提交。

所以在我的例子中，这仅仅意味着原点/主节点已经过时了。因为我知道没有其他人在触摸原点/master，修复是微不足道的:git push -f(其中-f表示力)

你可能会遇到这种情况，只需要从remote中获取1个历史记录:

$ git pull --depth=1
fatal: refusing to merge unrelated histories
$ git status
Your branch and 'origin/main' have diverged,
and have 1 and 1 different commits each, respectively.

根据上面的回答，会导致两个分支分流到不同的“线”，所以Git认为这是不相关的历史。

---a---b---main
        \      \
          x x x x   diverged, cannot be merged anymore
          \      \
    ---?---?---?---c(origin/main)

最后，简单的解决方案是:git重置-硬的origin/main，如果你不关心本地的变化，否则你将失去所有的工作。

或者尝试git pull——depth=2。

你可以用a来查看它们的区别:

git log HEAD..origin/main

# old repositories
git log HEAD..origin/master

(请参见“如何让git总是从特定的分支中提取?”)

注意:从Git 2.28 (Q3 2020)开始，默认的分支是可配置的，现在(2021+)设置为main，不再是master。 其余的答案反映了最近的习俗。

---

当你有这样的信息:

“你的分支和‘origin/main’已经分开了，#和分别有1个和1个不同的提交。”

检查是否需要更新原点。 如果origin是最新的，那么当您在本地进行自己的提交时，一些提交已经从另一个repo推送到origin。

... o ---- o ---- A ---- B  origin/main (upstream work)
                   \
                    C  main(your work)

您基于提交A提交C，因为这是您当时从上游获取的最新工作。

但是，在您试图推回原点之前，其他人推了提交B。 发展的历史已经分化成不同的道路。

然后，您可以合并或重新编制数据库。详见Pro Git: Git分支-重基。

走

使用git merge命令:

$ git merge origin/main

# old repositories
$ git merge origin/master

这告诉Git将来自origin/main的更改集成到您的工作中，并创建一个合并提交。 现在的历史图表是这样的:

... o ---- o ---- A ---- B  origin/main (upstream work)
                   \      \
                    C ---- M  main (your work)

新的合并(commit M)有两个父节点，每个父节点代表一条通向该提交中存储的内容的开发路径。

注意，M背后的历史现在是非线性的。

变基

使用git rebase命令:

$ git rebase origin/main

# old repositories
$ git rebase origin/master

这告诉Git重播提交C(你的工作)，就好像你是基于提交B而不是A。 CVS和Subversion用户在提交前更新时，通常会在上游工作的基础上重新构建本地更改。 Git只是在提交和重基步骤之间增加了显式的分隔。

现在的历史图表是这样的:

... o ---- o ---- A ---- B  origin/main (upstream work)
                          \
                           C'  main (your work)

Commit C'是git rebase命令创建的一个新提交。 它与C有两个不同之处:

它有着不同的历史:B而不是a。 它的内容解释了B和C的变化;它与合并示例中的M相同。

请注意，C'背后的历史仍然是线性的。 我们选择(目前)只允许cmake.org/cmake.git中的线性历史。 这种方法保留了以前使用的基于cvs的工作流，并且可以简化转换。 尝试将C'推入我们的存储库将会工作(假设您有权限，并且在您重基时没有人推过)。

git pull命令提供了一种简单的方法来从原点获取并在其上重新设置本地工作:

$ git pull --rebase

这将上面的获取和rebase步骤合并到一个命令中。

为了更直接地回答最初的问题，您可以检查实际冲突的差异:

git diff HEAD..origin/master

并使用此信息来决定是将源的更改拉到本地回购中，还是将本地更改推到源中。

我有这个问题，即使在阅读了上面的回复后，我也不知道是什么导致了它。我的解决办法是做

git reset --hard origin/master

然后，这只是将我的(本地)master副本(我认为是搞砸了)重置到正确的点，由(远程)origin/master表示。

警告:您将丢失所有尚未推送到原点/主节点的更改。