head通常指向当前分支的引用，即refs/heads/分支名，间接指向该分支最新提交；也可直接指向某次提交进入分离头状态（detached head），此时head成为游离指针，不关联任何分支。
Git 中的 HEAD 到底指向什么？
HEAD 不是分支名，而是当前工作区“所处位置”的指针。它通常指向某个分支（比如 refs/heads/main），而该分支又指向某个提交对象。但 HEAD 也可以直接指向提交（detached HEAD 状态）——这正是快速跳转历史节点的基础。
关键点在于：HEAD 可被显式移动，且所有基于 HEAD 的相对操作（如 HEAD~1、HEAD^2）都即时生效，无需先创建分支。
用 git checkout 或 git switch 直接跳到历史提交
想看某次提交的代码快照？不需要先 git branch 再 git checkout，一步到位即可：
-
git checkout HEAD~2：回退到当前提交往上数第 2 个祖先提交（线性历史下等价于倒数第 3 次提交） -
git checkout abc1234：跳转到指定 commit hash 对应的节点 -
git switch --detach HEAD^：更明确地进入 detached HEAD 状态，避免误提交提示干扰
注意：git checkout 在 Git 2.23+ 已被 git switch 和 git restore 分拆替代；若用 git checkout <commit></commit>，Git 会自动进入 detached HEAD，这是预期行为，不是错误。
HEAD 相对语法的常见陷阱
HEAD~n 和 HEAD^n 看似相似，语义完全不同：
-
HEAD~3表示“从HEAD开始，沿着第一个父提交连续向上走 3 步”，只适用于线性或主干路径 -
HEAD^2表示“HEAD的第二个父提交”，仅在 merge 提交中有效（^1是第一个父，即被合并进来的分支的 tip） -
HEAD~1^2这类组合写法合法，但可读性差，建议拆成两步验证 - 在 rebase 后的历史中，
HEAD~n的“n”可能因提交被重写而指向意料之外的节点——别依赖绝对数字，优先用git log --oneline -n 10辅助定位
跳转后如何安全返回、避免丢失工作
detached HEAD 下的任何新提交都不会属于任何分支，一旦切换走就难以找回：
- 如果只是查看，不修改：放心跳，
git switch -或git checkout -可秒回上一个分支 - 如果做了修改并提交：立即用
git branch temp-branch把当前HEAD保存为分支，再git switch main合并或 cherry-pick - 误删了 detached HEAD 上的提交？只要没执行
git gc，git reflog里还能找到它（git reset --hard HEAD@{2}可恢复）
最易被忽略的是：某些 GUI 工具或 IDE 插件会在 detached HEAD 下静默禁用提交按钮，却不提示原因——此时看一眼命令行的 git status 输出，第一行就会写明 “HEAD detached at abc1234”。
