为什么git revert会抱怨缺少-m选项？

所以我正在和其他人一起做一个项目，有多个github分叉正在进行中。有人刚刚解决了一个问题，我和他的叉子合并了，但后来我意识到我可以找到更好的解决方案。我想恢复我刚才所做的承诺。我尝试使用

git revert HEAD

执行此操作，但它给了我以下错误：

fatal: Commit <SHA1> is a merge but no -m option was given. 致命：提交是一个合并，但未提供-m选项。 这是什么意思？当我合并并提交时，我确实使用了-m选项来表示“与合并”

---

我在这里做错了什么？

默认情况下，git revert拒绝还原合并提交，因为这实际上意味着不明确。我假定您的

头实际上是一个合并提交

如果要还原合并提交，则必须指定要考虑的主干的父级，即要还原的父级。

通常情况下，这将是第一位家长，例如，如果您在
master
上执行
git merge-depured
，然后决定恢复
depured
的合并。第一个父级将是您的预合并
主分支
，第二个父级将是
不需要的
的提示

在这种情况下，您可以执行以下操作：

git revert -m 1 HEAD

假设另一个人在foo之上创建了bar，但你同时创建了baz，然后合并，给出了

$ git lola
*   2582152 (HEAD, master) Merge branch 'otherguy'
|\  
| * c7256de (otherguy) bar
* | b7e7176 baz
|/  
* 9968f79 foo
$ git lola
* e900aad (HEAD, master) Revert "Merge branch 'otherguy'"
*   2582152 Merge branch 'otherguy'
|\  
| * c7256de (otherguy) bar
* | b7e7176 baz
|/  
* 9968f79 foo
查尔斯·贝利像往常一样做了一个演讲。如中所示，使用git revert

$ git revert --no-edit -m 1 HEAD
[master e900aad] Revert "Merge branch 'otherguy'"
 0 files changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 bar
但我怀疑您想放弃合并提交：

$ git reset --hard HEAD^
HEAD is now at b7e7176 baz

$ git lola
* b7e7176 (HEAD, master) baz
| * c7256de (otherguy) bar
|/  
* 9968f79 foo
$git重置--硬头^
HEAD现在位于b7e7176 baz
$git lola
*b7e7176（负责人、船长）baz
|*c7256de（其他人）酒吧
|/  
*9968f79 foo
如文件所述

^
，例如HEAD^，
v1.5.1^0

修订参数的后缀
^
表示提交对象的第一个父对象
^
表示第n个父项（即
^
相当于
^1
）。作为一项特殊规则，
^0
表示提交本身，当
是引用提交对象的标记对象的对象名时使用

因此，在调用
git reset
之前，
HEAD^
（或
HEAD^1
）是b7e7176，
HEAD^2
是c7256de，即分别是合并提交的第一个和第二个父级

小心git reset--hard，因为它会破坏工作。
我遇到了这个问题，解决方案是查看提交图（使用gitk）并查看我的以下情况：

*   commit I want to cherry-pick (x)
|\  
| * branch I want to cherry-pick to (y)
* | 
|/  
* common parent (x)

我现在明白我想做什么了

git cherry-pick -m 2 mycommitsha

这是因为
-m1
将基于公共父级进行合并，其中as
-m2
基于分支y进行合并，而分支y正是我想要选择的分支。
在原始问题中，git错误的“-m选项”可能错误地表示提交消息。正如其他答案中所解释的，使用'-m n '指定合并的第n个父节点来选择你认为是主干的父。< /P>好的，谢谢。我发现只需更改受合并影响的两个文件，然后提交我的一些其他更改就更容易了。在哪里可以找到我是否必须使用-m1或-m2的信息？
git cat file-p[merge\u commit\u ID]
将按顺序显示父分支。列出的第一个将是
-m1
，第二个
-m2
git revert[HASH]-m2
在分支1.x-1.x上告诉我没有要提交的内容，工作目录是干净的，但我的提交没有被还原。因此，如果我需要在过去10次合并后还原（这很有可能是因为每次我从另一个开发人员那里获取更改时，git都会自动执行合并）每一次合并我都要这样做？这就是git粉丝如此热衷于重定基址的原因，因为revert基本上是无用的吗？这是一个混乱、混乱、混乱的世界。除了Lola。非常感谢这个奇妙的别名。向git命令添加
Lola
的简单方法：
git config--global alias.Lola“log--graph--decoration--pretty=oneline--abbrev commit--all"
可能是因为它与这个问题所涉及的
git revert
无关。我认为这个问题是关于
-m
选项，而不仅仅是关于
git merge
。也就是说，
-m
选项的使用背后的推理对于revert和cherry pick似乎是相似的。如果不是这样的话，请让我们知道。由于我还没有发现任何其他问题专门针对cherry pick的使用，感谢您的回答，这可能导致谷歌帮助我找到这个问题和有用的相关讨论！如果我理解正确，git没有哪个分支的记录（y）是在上创建的；据它所知，您的图片是对称的：左分支上的未命名提交在任何方面都不比右分支（y）上的提交好或坏。如果这是正确的，它如何确定哪个是1，哪个是2？
git cherry-pick -m 2 mycommitsha