我从这个链接找到了如何恢复合并的很好的解释，我复制粘贴了下面的解释，如果下面的链接不起作用，这将很有帮助。

如何还原错误合并艾伦(alan@clueserver.org)他说：

我有一个主分支。我们有一个分支开发人员正在进行工作。他们声称它已经准备好了。我们将其合并进入主分支。它打破了一些东西，所以我们恢复合并。他们对代码进行更改。他们会说没关系，我们再次合并。当检查时，我们发现在还原之前所做的代码更改不在主分支中，但之后的代码更改位于主分支中树枝并请求帮助从这种情况中恢复过来。

“恢复合并”后的历史记录如下所示：

---o---o---o---M---x---x---W
              /
      ---A---B

其中A和B处于不太好的侧开发中，M是将这些过早的更改引入主线的合并，x是与侧分支在主线上所做的和已经做的更改无关的更改，W是“合并M的恢复”（W看起来不是M颠倒了吗？）。IOW，“diff W^..W”类似于“diff-R M^..M”。

合并的“还原”可以通过以下方式进行：

$git还原-m 1 m在分支的开发人员纠正错误后，历史可能如下：

---o---o---o---M---x---x---W---x
              /
      ---A---B-------------------C---D

其中C和D将修复A和B中的损坏，并且您可能已经在W之后的主线上进行了一些其他更改。

如果您合并更新后的分支（顶端有D），那么在A或B中所做的任何更改都不会产生结果，因为它们被W还原。这就是Alan看到的。

Linus解释了情况：

恢复常规提交只会有效地撤消该提交确实如此，而且相当简单。但同时恢复合并提交撤消提交更改的数据，但它确实与合并对历史的影响无关。因此，合并仍将存在，并且仍将被视为加入这两个分支合并在一起，将来的合并将看到最后一个共享状态-以及还原合并带来的还原不会影响这一点。因此，“还原”可以撤消数据更改，但它在很大程度上不是“撤销”是指它不会撤销提交对存储库历史记录。所以，如果你把“恢复”看作“撤消”，那么你将永远错过了这部分回复。是的，它撤销了数据，但不，它没有撤消历史记录。在这种情况下，您需要首先还原上一个还原，这将使历史看起来像这样：

---o---o---o---M---x---x---W---x---Y
              /
      ---A---B-------------------C---D

其中Y是W的回复。这种“回复回复”可以通过以下方式完成：

$git还原W这段历史（忽略W和W..Y之间可能发生的冲突）相当于历史中根本没有W或Y：

---o---o---o---M---x---x-------x----
              /
      ---A---B-------------------C---D

并且再次合并侧分支将不具有由较早的恢复和恢复的恢复引起的冲突。

---o---o---o---M---x---x-------x-------*
              /                       /
      ---A---B-------------------C---D

当然，在C和D中所做的更改仍然可能与任何x所做的操作发生冲突，但这只是正常的合并冲突。

您可以按照以下步骤恢复不正确的提交或将远程分支重置回正确的HEAD/状态。

注意：此解决方案仅适用于您自己的分支，而不适用于共享的树枝

签出远程分支到本地回购。git签出您的branch_name从git日志中复制提交哈希（即错误提交前的提交id）git日志-n5

应该显示如下内容：

提交7cd42475d6f95f5896b6f02e902efab0b70e8038“合并分支“错误提交”到“your_branch_name”“提交”f9a734f8f44b0b37ccea769a2fd774c0f0c012“这是错误的提交”提交3779ab50e72908da92d2cfcd72256d7a09f444ba“这是正确的提交“

将分支重置为上一步中复制的提交哈希git reset＜commit hash＞（即3779ab50e72908da92d2cfcd72256d7a09f444ba）运行gitstatus以显示错误提交中的所有更改。只需运行gitreset——很难还原所有这些更改。强制将您的本地分支推到远程，并注意到您的提交历史记录与被污染之前一样干净。git push-f origin your_branch_name

在git-restore-m中，-m选项指定父编号。这是需要的，因为合并提交有多个父级，Git无法自动知道哪个父级是主线，哪个父级就是要取消合并的分支。

当您在git日志的输出中查看合并提交时，您将看到其父级列在以merge开头的行中：

commit 8f937c683929b08379097828c8a04350b9b8e183
Merge: 8989ee0 7c6b236
Author: Ben James <ben@example.com>
Date:   Wed Aug 17 22:49:41 2011 +0100

Merge branch 'gh-pages'

Conflicts:
    README

在这种情况下，git revert 8f937c6-m 1将获得8989ee0中的树，而git rever-m 2将恢复7c6b236中的树。

为了更好地理解父ID，可以运行：

git log 8989ee0 

and

git log 7c6b236

正如Ryan所提到的，git-restore可能会使合并变得困难，因此git-restore也许不是您想要的。我发现在这里使用git reset-hard<commit hash before merge>命令更有用。

完成硬重置部分后，可以强制推送到远程分支，即git push-f＜remote name＞＜remote branch name＞，其中＜remote name＞通常被命名为origin。从那时起，如果您愿意，可以重新合并。

为了保持日志的整洁（这种方法有一些缺点（由于push-f））：

git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>

“合并前提交哈希”来自合并后的日志（gitlog）。

我在一个已合并到GitHub回购主分支的PR上也遇到了这个问题。

因为我只是想修改一些修改过的文件，而不是PR带来的全部更改，所以我不得不用gitcommit-am修改合并提交。

步骤：

转到要更改/还原某些已修改文件的分支根据修改的文件执行所需的更改运行git-add*或git-add<file>运行gitcommit--am并验证运行git push-f

为什么有趣：

它使公关的作者承诺保持不变它不会破坏git树您将被标记为提交人（合并提交作者将保持不变）Git就像你解决了冲突一样，它会删除/更改修改文件中的代码，就像你手动告诉GitHub不要按原样合并它一样