revert <hash> 和 revert <head> 有什么区别？答案

【问题标题】：What's the difference between revert <hash> and revert <head>?revert <hash> 和 revert <head> 有什么区别？
【发布时间】：2020-06-15 21:34:10
【问题描述】：

我有 3 个提交推送到我的存储库。

提交3
提交2
提交1

所以，如果我尝试使用命令 git revert commit2Hash 恢复 Commit2，它将发出警报，以便在合并之前解决冲突。

但如果我尝试使用命令 git revert HEAD~1 恢复 Commit2，它将直接恢复 Commit2 而不会给我任何冲突。

请问，为什么会这样？

【问题讨论】：

因为HEAD~2 在您的示例中指向<commit1>
在您从HEAD~2 更正为HEAD~1 之后：两个引用现在都指向同一个东西。这两种语法（HEAD~1 和<commit2Hash>）之间没有任何区别。请仔细检查一个干净的示例，您会发现两个还原的行为完全相同。

标签： git github revert git-revert

【解决方案1】：

HEAD~0 是你的最新提交（也就是 HEAD）

HEAD~2 表示从零开始计数的第二次提交的哈希值。

所以，输入 git revert HEAD~2 您正在尝试恢复 Commit1。这就是区别。

【讨论】：

感谢您的建议。我将帖子编辑到 Head~1。我的问题还在继续：D
@RenzoRodrigues 在遇到合并冲突后，您是否完成了git revert --abort？
该命令只会中止还原，对吗？我想了解使用哈希而不是 head 时幕后会发生什么。我刚刚找到了这个带有解释的链接。一些疑问仍然存在。 monarchdigital.com/blog/2015-04-21/…
@RenzoRodrigues 是的，你是对的。我只是想确认你没有犯错。正确的场景意味着在尝试通过哈希恢复之前中止第一个合并冲突（当您使用哈希时）。因为我看到了在解决合并冲突的同时成功中止 commit1 的可能性。能否请您提供一些日志、状态和重现步骤？

【解决方案2】：

没有--graph 的git log 的输出总是线性的，但真实的历史可能是平行的。当git log 打印时

commit3
commit2
commit1

HEAD~1 可以等价于commit1 而不是commit2。使用git log --oneline --graph --decorate查看真实历史。当commit2 和commit1 发散并且commit3 是合并提交时，就会发生这种情况。

【讨论】：