Git合并后HEAD^指向的提交是哪个？为何不是预期的前序提交？

核心原因 #

Git 合并提交的父节点顺序有严格规则：

• 第一个父节点（HEAD^ / HEAD^1）：执行 git merge 命令时，当前所在分支的原有 HEAD
• 第二个父节点（HEAD^2）：被合并进来的分支的 HEAD

从你提供的提交线可以看出，新合并提交 461eb66 的第一个父节点是 7ea521f，第二个父节点才是 38f4e95，说明你执行合并操作时，本地 main 分支的 HEAD 还停留在老版本 7ea521f，没有同步到远端最新的 38f4e95，才会出现和你预期不符的情况。

问题1：为什么HEAD^2才符合你对HEAD^的预期 #

本质就是你执行合并前本地main分支不是最新的38f4e95版本，你合并进来的待合入分支反而因为你提前把main合并进了待合入分支，其HEAD刚好是38f4e95，所以第二个父节点才是你以为的「合并前的HEAD」。

问题2：先把main合并到待合入分支的习惯会不会导致这个问题 #

这个习惯本身是合理的，不会直接导致问题。真正的诱因是你把待合入分支合并回main之前，没有先执行git pull把本地main同步到和远端一致的最新版本，本地main还停留在旧提交就直接执行了合并。

问题3：撤销合并的更可靠方案 #

不用提前记提交哈希，也不用依赖远端重置，有两个更简单的方案：

• 如果你合并后还没有把提交推送到远端：直接执行git reset --hard ORIG_HEAD即可。Git在执行合并、变基等高危操作前，会自动把操作前的HEAD指针存到ORIG_HEAD中，指向的就是你合并前的main分支状态，比找父节点更稳妥。
• 如果你已经把合并提交推送到了远端，需要公共分支回滚：执行git revert -m 1 <合并提交哈希>，-m 1表示保留当前分支第一个父节点的代码，如果需要保留被合并分支的代码就改成-m 2。

内容的提问来源于stack exchange，提问作者Chris F Carroll