直接查看 .git/head 文件内容是最直观方式：若为 ref: refs/heads/main 表示正常绑定分支，若为 e5d3d4a3... 哈希值则表示 detached head 状态。
HEAD 文件内容直接暴露指向类型
最直观的方式是查看 .git/HEAD 文件内容，它不抽象、不绕弯，就是 Git 实际存储的原始状态。
执行 cat .git/HEAD 后，你只会看到两种格式：
-
ref: refs/heads/main→ 表示 HEAD 正常绑定在main分支上，后续git commit会自动推进该分支指针 -
e5d3d4a3...（一串 40 位哈希）→ 表示处于分离头（detached HEAD）状态，HEAD 直接指向某次提交，不关联任何分支
注意：不要依赖 git status 的输出来判断是否 detached —— 它有时只写 “HEAD detached at xxx”，有时又省略，而 .git/HEAD 永远真实可靠。
git rev-parse --abbrev-ref HEAD 返回分支名还是 ‘HEAD’
这个命令是脚本中判断当前是否在分支上的常用手段，但它的行为有明确边界：
- 当
.git/HEAD是ref: refs/heads/feature时，git rev-parse --abbrev-ref HEAD输出feature - 当
.git/HEAD是提交哈希时，它就老老实实输出HEAD（字面量），不是错误，是设计如此 - 它不会输出
detached或其他提示 —— 所以脚本里要靠判断返回值是否等于HEAD来识别分离状态
例如：if [ "$(git rev-parse --abbrev-ref HEAD)" = "HEAD" ]; then echo "detached"; fi
git branch 命令里的星号 * 只反映 HEAD 当前所指
git branch 列出所有本地分支，并用 * 标出当前 HEAD 所在位置。但它不告诉你 HEAD 是“真分支”还是“假分支”：
- 如果
* main，且.git/HEAD是ref: refs/heads/main→ 正常 - 如果
* (HEAD detached at abc123)→ 明确提示分离，此时*其实没指向分支名，只是标记了当前提交上下文 - 如果
* main但.git/HEAD内容是哈希 → 这种情况**不可能发生**，git branch的星号永远和.git/HEAD保持一致；若看到矛盾，说明仓库元数据已损坏
切换分支时 HEAD 和分支指针的联动关系
执行 git checkout dev 或 git switch dev 不是“把代码切过去”，而是两步原子操作：
- 把 HEAD 指针从原
ref: refs/heads/main改为ref: refs/heads/dev - 把工作目录文件重置为
dev分支最新提交（即dev指向的那个 commit）的快照
关键点在于：分支指针（如 dev）本身是独立存在的，HEAD 只是“选中”它。你可以用 git branch -f dev abc123 强行移动 dev 指针，但只要 HEAD 还指着 main，就不会影响当前工作区。
容易被忽略的是：只有当 HEAD 指向一个分支引用（而非提交哈希）时，git commit 才会同时更新该分支指针；否则新提交将游离无主，除非立刻用 git branch new-branch 拉一条分支出来接住它。
