HEAD~n 按提交拓扑（parent 链）倒推，要求线性或明确单路径；HEAD@{n} 按 reflog 时间线倒查，记录本地操作历史，不依赖拓扑结构。
HEAD~n 和 HEAD@{n} 的本质区别在哪
很多人混淆 HEAD~n 和 HEAD@{n}，以为都是“往前数 n 步”，结果 checkout 或 reset 时出错。根本区别在于：前者按**提交拓扑结构**（parent 链）倒推，后者按**本地 reflog 记录**（操作时间线）倒查。
HEAD~3 意味着“当前提交的第 3 级父提交”，必须存在连续的单父链；而 HEAD@{2} 是“HEAD 在 2 次操作前指向的提交”，哪怕中间切换过分支、做了 merge、甚至执行了 git reset --hard，只要没清空 reflog，它就还在。
-
HEAD~n不依赖 reflog，但要求提交图谱是线性或可明确追溯的单路径 -
HEAD@{n}完全依赖.git/logs/HEAD文件，只记录你本地执行过的移动操作（checkout、commit、reset、merge 等） - reflog 默认保留 30 天或 90 次操作（由
gc.reflogExpire和gc.reflogExpireUnreachable控制），超期自动清理
什么时候必须用 HEAD@{n} 而不能用 HEAD~n
典型场景是误操作后想找回“刚刚删掉的提交”——比如你刚 git reset --hard HEAD~2，又立刻 git checkout feature-branch，这时 HEAD~1 已经指向新分支起点，完全找不到原提交；但 HEAD@{1} 还存着 reset 前的位置，HEAD@{2} 可能就是你刚丢掉的 commit。
- 执行过
git reset --hard后想恢复被丢弃的提交 - 频繁在多个分支间
git checkout，需要回到“上上周 checkout 的那个提交” - merge 或 rebase 中途 abort，想回退到操作开始前的 HEAD 状态
-
git reflog输出里能看到HEAD@{0}: reset: moving to HEAD~2这类记录，说明该位置可安全引用
HEAD~n 在 merge 提交上容易踩的坑
merge 提交有两个 parent：HEAD~1 是第一个 parent（通常是当前分支旧 tip），HEAD~2 是第二个 parent（通常是被合并进来的分支 tip）。但 HEAD~3 会报错：Git 不知道该从哪个 parent 继续往上找 —— 它默认只沿第一个 parent 回溯。
想明确指定第二个 parent 的子树，得用 HEAD^2（注意是 ^ 不是 ~），HEAD^2~1 才等价于“第二个 parent 的父提交”。而 HEAD~2 在 merge 提交上永远等于 HEAD^2，但语义模糊，易误导。
- 对 merge 提交，
HEAD~n仅等价于沿 first-parent 链走 n 步，和git log --first-parent行为一致 - 需要访问 second-parent 分支历史时，优先用
HEAD^2、HEAD^2~3，避免用HEAD~n推算 -
git show HEAD~2在 merge 提交上可能显示意料之外的提交，建议先git show --pretty=%P HEAD看 parent 列表再决定用 ^ 还是 ~
如何验证你引用的确实是想要的提交
别急着 git reset 或 git checkout，先确认目标提交是否如预期。最稳妥的方式是组合使用 git reflog 和 git log -n 5 --oneline 对照看。
- 运行
git reflog，找到类似abc1234 HEAD@{3}: checkout: moving from main to dev的行，记下HEAD@{3} - 执行
git show --oneline HEAD@{3}，检查输出的提交信息、作者、时间是否匹配你的记忆 - 如果要用
HEAD~n，先git log --oneline -n 10看最近提交链，数清楚层级，尤其注意是否有 merge 提交打断线性 - 对关键操作，加
--dry-run参数（如git reset --hard --dry-run HEAD@{1}）预览影响范围（部分 Git 版本支持）
reflog 是本地的、不共享的，HEAD@{n} 在 clone 出来的新仓库里不存在；而 HEAD~n 只要提交存在，任何克隆库都能解析。这点常被忽略，协作时别把 HEAD@{n} 写进文档或脚本里。
