执行git checkout HEAD~N无法跳转到预期提交该如何解决

现象原因 #

• HEAD~N 操作符的逻辑是沿着提交链的第一个父提交连续回溯N步，遇到合并提交时，只会选择当前分支的直接父提交，被合并分支上的所有提交不会计入~操作符的回溯步数。
• 默认git log --oneline的输出是按提交时间倒序排列的，并非严格对应当前分支的父提交链，结果中会混杂被合并分支的提交。你从这个结果中数出的5条提交，并不等于HEAD~N会回溯的5个父提交，中间混入的合并提交和被合并分支提交，导致实际回溯步数远超预期。
• 你提供的提交记录中存在多个合并提交（93eeda7为PR224合并提交、7a162e3为PR223合并提交），这类多父提交是导致步数计算错乱的核心原因。

正确检出指定提交的方法 #

• 如果你需要按当前分支的直接父链回溯N步，先执行以下命令查看纯净的父链提交列表：

  git log --oneline --first-parent -n 10
  

  该命令会过滤掉所有被合并分支的提交，只保留当前分支的直接提交记录，在这个结果中数出对应的N步后再执行git checkout HEAD~N即可符合预期。
• 如果你要指定默认git log输出中的某条提交，最精准的方式是直接使用提交哈希检出，比如要切换到7a162e3对应的提交，直接执行：

  git checkout 7a162e3
  

• 如果你需要访问合并提交的其他父提交，可以使用^操作符指定父提交序号，比如HEAD^2代表当前HEAD（合并提交）的第二个父提交，也就是被合并分支的头提交。

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