为什么 git revert 会抱怨缺少 -m 选项？
我正在与其他人一起开发一个项目，并且正在开发多个 GitHub 分支。有人刚刚修复了一个问题，我与他的分支合并，但后来我意识到我可以找到更好的解决方案。我想恢复我刚刚所做的提交。我尝试使用 git revert HEAD 执行此操作，但它给了我这个错误：
fatal: Commit <SHA1> is a merge but no -m option was given.
这是什么意思？当我合并并提交时，我确实使用 -m 选项来表示“与 <用户名> 合并”。
我在这里做错了什么？
I'm working on a project with other people, and there are multiple GitHub forks being worked on. Someone just made a fix for a problem and I merged with his fork, but then I realized that I could find a better solution. I want to revert the commit I just made. I tried doing this with git revert HEAD but it gave me this error:
fatal: Commit <SHA1> is a merge but no -m option was given.
What does that mean? When I merged and committed, I did use the -m option to say "Merged with <username>".
What am I doing wrong here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
默认情况下，git revert 拒绝恢复合并提交，因为这实际上意味着什么是不明确的。我认为您的
HEAD实际上是合并提交。如果你想恢复合并提交，你必须指定你想将哪个合并父级视为主干，即你想恢复到什么。
通常这将是第一个父级，例如，如果您在
master上并进行了git merge Unwanted，然后决定恢复unwanted的合并。第一个父级将是您的预合并master分支，第二个父级将是unwanted的尖端。在这种情况下，您可以执行以下操作：
git cat-file -p [MERGE_COMMIT_ID]将按顺序显示父分支。列出的第一个是 -m 1，第二个是 -m 2。By default
git revertrefuses to revert a merge commit as what that actually means is ambiguous. I presume that yourHEADis in fact a merge commit.If you want to revert the merge commit, you have to specify which parent of the merge you want to consider to be the main trunk, i.e. what you want to revert to.
Often this will be parent number one, for example if you were on
masterand didgit merge unwantedand then decided to revert the merge ofunwanted. The first parent would be your pre-mergemasterbranch and the second parent would be the tip ofunwanted.In this case you could do:
git cat-file -p [MERGE_COMMIT_ID]will show the parent branches in order. The first one listed would be -m 1, the second -m 2.假设另一个人在 foo 之上创建了 bar，但您同时创建了 baz，然后合并，给出了
注释的历史记录： git lola 是一个非标准但有用的别名。
git revert没有骰子：Charles Bailey 像往常一样给出了出色的答案。使用
git revert有效删除
bar并生成以下历史记录但我怀疑您想丢弃合并提交：
如文档中所述
git rev-parse手册因此在调用
git reset之前，HEAD^（或HEAD^1）是 b7e7176，HEAD^2是 c7256de ，ie，分别是合并提交的第一个和第二个父级。请小心使用
git reset --hard，因为它可能会破坏工作。Say the other guy created bar on top of foo, but you created baz in the meantime and then merged, giving a history of
Note: git lola is a non-standard but useful alias.
No dice with
git revert:Charles Bailey gave an excellent answer as usual. Using
git revertas ineffectively deletes
barand produces a history ofBut I suspect you want to throw away the merge commit:
As documented in the
git rev-parsemanualso before invoking
git reset,HEAD^(orHEAD^1) was b7e7176 andHEAD^2was c7256de, i.e., respectively the first and second parents of the merge commit.Be careful with
git reset --hardbecause it can destroy work.我遇到了这个问题，解决方案是查看提交图（使用 gitk）并看到我有以下内容：
我现在明白我想要这样做
这是因为
-m 1会基于合并在公共父级上，-m 2基于分支 y 合并，这就是我想要挑选的分支。I had this problem, the solution was to look at the commit graph (using gitk) and see that I had the following:
I understand now that I want to do
This is because
-m 1would merge based on the common parent where as-m 2merges based on branch y, that is the one I want to cherry-pick to.在最初的问题中，git 错误的“-m 选项”可能被错误地表示提交消息。正如其他答案中所解释的，使用“-m n”指定合并的第 n 个父级，以选择您认为是主干的父级。
In the original question, the '-m option' of the git error was probably mistaken to denote a commit message. As explained in the other answers, use '-m n' to specify the nth parent of the merge to pick the parent you consider to be the main trunk.