git revert <commit_hash> 单独是行不通的。 -m 必须指定，我对此感到很困惑。
以前有人经历过吗？
【问题讨论】：
git 的设计与每个人都使用的git-flow-ish 工作流程不匹配的示例。如果您已签出 develop，当然您希望恢复引入错误的 2-commit 功能分支，而不是多年的共享开发分支。需要用-m 1 来选择它感觉很荒谬。
标签： git
-m 选项指定父编号。这是因为一个合并提交有多个父级，并且 Git 不会自动知道哪个父级是主线，哪个父级是您要取消合并的分支。
当您在git log 的输出中查看合并提交时，您将看到其父项列在以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 revert -m 2 将恢复 7c6b236 中的树。
为了更好地理解父 ID，您可以运行：
git log 8989ee0
和
git log 7c6b236
【讨论】：
8989ee0，7c6b236，选择哪一个。我怎么理解？
git log 8989ee0 和git log 7c6b236，你应该知道答案。
这是一个完整的示例，希望对某人有所帮助：
git revert -m 1 <commit-hash>
git push -u origin master
其中<commit-hash> 是您想要还原的合并的提交哈希，正如this answer 的解释中所述，-m 1 表示您想要还原到第一个父级的树在合并之前。
git revert ... 行实质上是提交您的更改，而第二行通过将更改推送到远程分支来公开您的更改。
【讨论】：
git revert 命令已经提交了创建的提交对象。为避免这种情况发生，您必须输入 --no-commit 标志
revert 命令包含一个提交。
Ben 已经告诉过你如何恢复合并提交，但它非常重要你意识到这样做
"...声明您永远不会希望合并带来的树更改。因此，以后的合并只会带来提交引入的树更改，这些提交不是先前恢复的合并的祖先。这可能是也可能不是你想要的。" (git-merge man page)。
从手册页链接的article/mailing list message 详细说明了所涉及的机制和注意事项。只要确保您了解，如果您恢复合并提交，您就不能稍后再次合并分支并期望相同的更改回来。
【讨论】：
您可以按照这些步骤恢复不正确的提交或将远程分支重置为正确的 HEAD/状态。
git checkout your_branch_name
git log -n5
应该显示如下内容：
commit 7cd42475d6f95f5896b6f02e902efab0b70e8038 "合并分支 '错误提交' 到 'your_branch_name'"
提交 f9a734f8f44b0b37ccea769b9a2fd774c0f0c012 “这是一个错误的提交” 提交 3779ab50e72908da92d2cfcd72256d7a09f446ba “这是正确的 提交”
git reset <commit-hash> (i.e. 3779ab50e72908da92d2cfcd72256d7a09f446ba)
git status 以显示属于错误提交的所有更改。git reset --hard 即可恢复所有这些更改。git push -f origin your_branch_name
注意：此解决方案仅适用于您自己的分支，而不适用于共享分支。
【讨论】：
git revert -m 1 <merge-commit>
【讨论】：
1 以及何时不想使用。
在没有发生任何事情的情况下保持日志干净（这种方法有一些缺点（由于 push -f））：
git checkout <branch>
git reset --hard <commit-hash-before-merge>
git push -f origin HEAD:<remote-branch>
'commit-hash-before-merge'来自合并后的日志（git log）。
【讨论】：
push -f
git log 来确定commit-hash-before-merge 并不简单，因为提交会随着时间的推移交织在一起——我想知道这是否总是MERGECOMMIT^（这似乎表示是git-tower.com/learn/git/faq/undo-git-merge/…)?
有时最有效的回滚方式是后退和替换。
git log
使用第二次提交散列（完整散列，在列出的错误之前要恢复的散列），然后从那里重新分支。
git checkout -b newbranch <HASH>
然后删除旧分支，将新分支复制到它的位置并从那里重新启动。
git branch -D oldbranch
git checkout -b oldbranch newbranch
如果已广播，则从所有存储库中删除旧分支，将重做分支推送到最中心，然后将其拉回全部。
【讨论】：
所有答案已经涵盖了大部分内容，但我会加上我的 5 美分。 简而言之，恢复合并提交非常简单：
git revert -m 1 <commit-hash>
如果您有权限，您可以将其直接推送到“master”分支，否则只需将其推送到您的“revert”分支并创建拉取请求。
您可以在此处找到有关此主题的更多有用信息：https://itcodehub.blogspot.com/2019/06/how-to-revert-merge-in-git.html
【讨论】：
如果您想恢复 merge 提交，您必须执行以下操作。
git log 以找到您的合并提交的ID。您还会发现与合并关联的多个父 ID（见下图）。记下黄色显示的合并提交 ID。
父 ID 是写在下一行的 Merge: parent1 parent2。现在...
短篇小说：
git revert <merge commit id> -m 1，它将打开一个vi 控制台以输入提交消息。写入，保存，退出，完成！长篇大论：
切换到进行合并的分支。就我而言，它是 test 分支，我正在尝试从中删除 feature/analytics-v3 分支。
git revert 是恢复任何提交的命令。但是在恢复 merge 提交时有一个讨厌的技巧。您需要输入-m 标志否则它将失败。从这里开始，您需要决定是否要恢复您的分支并使其看起来与 parent1 或 parent2 上的完全相同，通过：
git revert <merge commit id> -m 1（恢复为parent2）
git revert <merge commit id> -m 2（恢复为parent1）
您可以对这些父母进行 git log 以确定您想走哪条路，这就是所有混乱的根源。
【讨论】：
我从link 找到了关于如何恢复合并的很好的解释，我复制粘贴了下面的解释，以防万一下面的链接不起作用。 p>
如何恢复错误的合并 Alan(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 revert -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 解释情况：
恢复常规提交只会有效地撤消该提交 做到了，而且相当简单。但也恢复合并提交 撤消提交更改的 data，但它确实如此 合并对 history 的影响没有任何影响。 所以merge还是会存在的，还是会被看成join的 两个分支在一起，未来的合并将看到合并为 最后一个共享状态 - 以及恢复合并的恢复带来 in 根本不会影响这一点。 因此，“还原”会撤消数据更改，但它不是 “撤消”是指它不会撤消提交对 存储库历史记录。 因此，如果您将“还原”视为“撤消”，那么您将始终 错过这部分回复。是的，它会撤消数据，但不，它不会 撤消历史。 在这种情况下，您可能希望先还原上一次还原，这会使历史看起来像这样：
---o---o---o---M---x---x---W---x---Y
/
---A---B-------------------C---D
其中 Y 是 W 的还原。这样的“还原的还原”可以通过以下方式完成：
$ git revert W 这段历史将（忽略 W 和 W..Y 更改之间可能存在的冲突）等同于历史中根本没有 W 或 Y：
---o---o---o---M---x---x-------x----
/
---A---B-------------------C---D
并且再次合并侧分支不会因为之前的revert和revert的revert而产生冲突。
---o---o---o---M---x---x-------x-------*
/ /
---A---B-------------------C---D
当然，在 C 和 D 中所做的更改仍然可能与任何 x 所做的冲突，但这只是正常的合并冲突。
【讨论】：
当您在git log 的输出中查看合并提交时，您将看到其父项列在以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 revert -m 2 将恢复 7c6b236 中的树。
为了更好地理解父 ID，您可以运行：
git log 8989ee0
和
git log 7c6b236
建立一个备份分支
git checkout -b mybackup-brach
git reset --hard 8989ee0
git push origin -u mybackup-branch
所以现在你有了合并前的更改，如果一切正常，签出到上一个分支并使用备份分支重置
git reset --hard origin/mybakcup-branhc
【讨论】：
这是一个非常古老的线程，但我认为我缺少另一个方便的解决方案：
我从不还原合并。我只是从一切正常的修订版中创建另一个分支，然后从中间添加的旧分支中挑选需要挑选的所有内容。
所以，如果 GIT 历史是这样的：
我从 a 创建一个新分支，选择 c 和 d，然后从 b 中清除新分支。我可以决定再次在我的新分支中合并“b”。旧分支已弃用，如果不再需要“b”或仍在另一个（功能/修补程序）分支中，则将删除旧分支。
现在唯一的问题是计算机科学中最困难的事情之一：您如何命名新分支？ ;)
好的，如果你失败了，尤其是。在 devel 中，您如上所述创建 newdevel，删除旧的 devel 并将 newdevel 重命名为 devel。 任务完成。您现在可以在需要时再次合并更改。就像以前从未合并过一样......
【讨论】：
我发现在两个已知端点之间创建一个反向补丁并应用该补丁会起作用。这假定您已经从 master 分支甚至是 master 分支的备份（例如 master_bk_01012017）创建了快照（标签）。
假设你合并到 master 的代码分支是 mycodebranch。
git diff --binary master..master_bk_01012017 > ~/myrevert.patch
git apply --check myrevert.patch
git am --signoff < myrevert.patch
git branch mycodebranch_fix
git checkout mycodebranch_fix
git revert [SHA]
【讨论】：
正确标记的答案对我有用，但我不得不花一些时间来确定发生了什么。所以我决定为像我这样的案例添加一个简单直接的步骤的答案..
假设我们有分支 A 和 B.. 你将分支 A 合并到分支 B 并将分支 B 推送到它自己，所以现在合并是它的一部分.. 但是你想回到最后一次提交 之前 合并.. 你是做什么的？
git log
您将看到最近提交的历史记录 - 提交具有提交/作者/日期属性，而合并也具有合并属性 - 因此您会看到它们：
commit: <commitHash>
Merge: <parentHashA> <parentHashB>
Author: <author>
Date: <date>
使用git log <parentHashA> 和git log <parentHashB> - 你会看到这些父分支的提交历史 - 列表中的第一个提交是最新的
<commitHash>，转到您的 git 根文件夹并使用git checkout -b <newBranchName> <commitHash> - 这将从您在合并之前选择的最后一个提交开始创建一个新分支。瞧，准备好了！ 【讨论】：
关于 git revert -m 的 git doc 提供了一个链接，准确地解释了这一点： https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt
【讨论】：
-m1 是当前正在修复的分支的最后一个父级，-m 2 是合并到此分支的原始父级。
如果命令行令人困惑，Tortoise Git 也可以在这里提供帮助。
【讨论】：
我在已合并到 GitHub 存储库的主分支的 PR 上也遇到了这个问题。
由于我只是想修改一些修改过的文件而不是 PR 带来的全部更改，我不得不 amend merge commit 和 git commit --am。
步骤：
git add * 或git add <file>
git commit --am 并验证git push -f
为什么有趣：
【讨论】：
如果您希望恢复刚才推送的更改，这是一个非常简单的答案：
commit 446sjb1uznnmaownlaybiosqwbs278q87
Merge: 123jshc 90asaf
git revert -m 2 446sjb1uznnmaownlaybiosqwbs278q87 //does the work
【讨论】：
正如 Ryan 提到的，git revert 可能会使合并变得困难，因此git revert 可能不是您想要的。我发现在这里使用git reset --hard <commit-hash-prior-to-merge> 命令更有用。
完成硬重置部分后，您可以强制推送到远程分支，即git push -f <remote-name> <remote-branch-name>，其中<remote-name> 通常被命名为origin。从那时起，您可以根据需要重新合并。
【讨论】：