我发现在两个已知端点之间创建一个反向补丁，然后应用该补丁即可。这假设您已经创建了主分支的快照（标记），甚至是主分支的备份，比如master_bk_011012017。

假设你合并到master的代码分支是mycodebranch。

签出主机。在主服务器和备份服务器之间创建一个完整的二进制反向修补程序。gitdiff—二进制主文件。。master_bk_01017>~/myrevert.patch检查您的补丁git apply--检查myevert.patch签署后应用修补程序git am--签出<myevert.patch如果修复后需要再次引入此代码，则需要从还原的主节点分支并签出修复分支git分支分支分支修复git校验mycodebranchfix在这里，您需要找到还原的SHA密钥并还原还原git还原现在，您可以使用mycodebranch_fix来解决问题，提交并在完成后重新合并到master中。

git文档关于git revert-m提供了一个链接，准确地解释了这一点：https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt

所有的答案已经涵盖了大部分内容，但我还要加上我的5美分。简而言之，恢复合并提交非常简单：

git revert -m 1 <commit-hash>

如果您有权限，可以将其直接推送到“主”分支，否则只需将其推送到“还原”分支并创建拉取请求。

您可以在此处找到有关此主题的更多有用信息：https://itcodehub.blogspot.com/2019/06/how-to-revert-merge-in-git.html

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

如何还原错误合并艾伦(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所做的操作发生冲突，但这只是正常的合并冲突。

下面是一个完整的示例：

git revert -m 1 <commit-hash> 
git push -u origin master

git还原。。。提交您的更改。

-m1表示您希望在合并之前恢复到第一个父级的树，如下面的答案所述。＜commit hash＞是要还原的合并的提交哈希。

git推。。。将更改推送到远程分支。

Ben已经告诉过您如何恢复合并提交，但您必须意识到这样做非常重要

“…声明您永远不希望合并带来的树更改。因此，以后的合并只会带来由不是先前还原的合并的祖先的提交引入的树更改，这可能是您想要的，也可能不是您想要的。”（git merge手册页）。

从手册页链接的文章/邮件列表消息详细说明了所涉及的机制和注意事项。只需确保您理解，如果您恢复合并提交，您不能只是稍后再次合并分支并期望相同的更改返回。