git reset --soft异常求助：执行HEAD~3未按预期重置提交

哦，这种情况我太熟悉了！大概率是你提交历史里的合并提交在搞鬼，而你之前手动解决合并冲突后生成的那个提交就是关键原因。

先给你掰明白HEAD~3到底是怎么工作的：Git里的HEAD~n是沿着当前分支的第一个父提交链往上数n个提交，但合并提交比较特殊——它有两个父节点（合并时的两条分支各自的最后一个提交）。这时候HEAD~n会默认走合并提交的第一个父节点（也就是你执行合并操作时当前所在分支的那条线），但合并提交本身会被算成1个提交节点，这就会导致你以为的“3次提交”和实际回退的次数完全不符。

举个简单的例子，假设你的提交历史是这样的：

A -- B -- C -- M -- D -- E -- F (当前HEAD)
     \        /
      X -- Y -- Z

这里的M就是你解决冲突后生成的合并提交。当你执行git reset --soft HEAD~3时，Git会从F开始往上数3个父节点：F→E→D→M→C，所以最终会回退到C，相当于跳过了F、E、D、M这4个提交，远超过你预期的3次。

至于你说测试时重置的提交数“随机”，其实一点都不随机——只是每次测试时你的HEAD位置不同，而提交历史里的合并节点位置不一样，导致HEAD~n实际指向的祖先提交和你预想的完全不在一条线上，所以看起来次数没规律。

怎么解决这个问题？ #

• 先看清提交历史：执行git log --oneline --graph，用图形化的方式查看你的提交链，这样就能一眼看到有没有合并提交，以及HEAD~3到底会指向哪个节点。
• 用哈希值精确指定：找到你想回退到的那个提交的哈希值（可以从git log里复制），直接执行git reset --soft <提交哈希>，这是最稳妥的方式，绝对不会出错。
• 改用交互式变基：如果你的需求是合并最近3次提交，更推荐用git rebase -i HEAD~3，这个命令会弹出一个编辑界面，让你清晰看到要操作的提交列表，你可以把需要合并的提交标记为squash，操作更直观，也不容易踩坑。

内容的提问来源于stack exchange，提问作者jhon354