先记住这个答案
HEAD 通常是一个符号引用，指向当前分支名，分支名再指向具体提交。detached HEAD 时，HEAD 直接指向某个提交。此时提交新工作后，HEAD 会移到新提交，但没有分支指向它，切走后再回来需靠 reflog 找哈希。用 git branch <新名> <哈希> 或 git checkout -b <名> <哈希> 可重新建立引用，防止提交被 Git 垃圾回收。
- HEAD 是指向当前分支或提交的指针。
- 游离态提交无分支引用，易被误认为丢失。
- 用 reflog 查哈希可找回提交并建新分支。
HEAD 的指向规则与游离触发
Git 维护一个名为 HEAD 的引用，通常它是符号引用，内容为 ref: refs/heads/main 这类路径。Git 用 HEAD 决定当前工作目录对应哪条分支，提交时分支指针随新提交前移。执行 git checkout <commit-hash> 或 git checkout <tag> 时，HEAD 不再指向分支，而直接写入该提交的哈希值，于是进入 detached HEAD。
此时工作区内容与指定提交一致，后续提交会沿当前提交创建新对象，但没有任何分支名记录这个新链。可以用 git log -1 确认 HEAD 位置，用 git status 会提示当前不位于任何分支。HEAD 可看作一个可移动游标，脱离分支后所有提交都建立在无分支引用的基线上。
在游离 HEAD 上做修复并找回的实例
假设你在 main 分支的提交 A 工作，为验证旧版本性能，执行 git checkout v2.0（标签指向提交 B），随后发现必须修复一个只在该版本出现的紧急漏洞。你直接修改并提交，得到提交 C，HEAD 指向 C，但 main 仍指向 A，没有任何分支指向 C。现在切换回 main 执行 git checkout main，C 成为悬空提交。
若想保留 C，立即执行 git log -g --oneline 或 git reflog，会看到 HEAD@{0} 或更早位置记录 C 的哈希。用 git branch hotfix-2.0 <C的哈希> 创建分支，或 git checkout -b hotfix-2.0 <哈希> 直接切过去。此后 main 不受影响，修复独立成分支。如果再执行 git checkout main，C 仍可通过新分支访问，不会丢失。
# 情景：在标签 v2.0 上提交后切走
git checkout v2.0 # detached HEAD
echo 'fix' >> bug.txt
git commit -am 'fix old bug' # commit C
# 切走前或后发现丢失，用 reflog 查找
git reflog | head -20 # 找到 commit 的哈希，如 abc1234
git branch hotfix-2.0 abc1234 # 重新建立分支引用
# 另一种方式：直接创建并切换到新分支
git checkout -b hotfix-2.0 abc1234适用于 Bash 环境，展示核心找回操作。reflog 输出中的 C 提交可用 HEAD@{n} 或直接哈希引用。
找回操作的失效边界
依赖 reflog 找回并非无限可靠。reflog 默认只保存 90 天（可由 gc.reflogExpire 调整），且当存储库执行 git gc --prune=now 或运行清理命令时会主动删除未被引用且超过生存期的对象。如果一个游离提交被遗忘很久，可能已经无法用 reflog 看到。
即便 reflog 已清空，若提交仍未被垃圾回收，可用 git fsck --lost-found 扫描悬空对象，但未必能直观识别哪个是你想要的。最稳妥的做法是进入 detached HEAD 后立即创建一个临时分支，或在离开前用 git tag 标记位置。相比依赖事后恢复，事前建立引用成本几乎为零。
容易答错的地方
- 认为切走就永久丢失
- 事实是提交对象仍在
.git/objects中，只是失去分支指针。只要 reflog 中仍有该提交的记录，Git 就不会把它当作未引用对象回收，因此可以找回；reflog 记录默认保留 90 天，但可被git reflog expire显式清理，之后若仓库运行垃圾回收，提交可能被删除。 - 把 detached HEAD 和空分支混淆
- detached HEAD 是指向具体提交，不是未创建分支。有些人误以为此时提交会进入无头状态，其实 HEAD 只是直接指向对象，提交依然会更新这个指针。
面试官还会怎么问？
detached HEAD 状态会自动触发吗？
不会默认触发。当你 checkout 一个分支或新提交时，只有显式指定提交哈希、标签或远程跟踪分支名称（如 origin/main）时才会变成 detached。切换回本地分支后恢复正常。
如何防止意外进入 detached HEAD？
避免直接 checkout 提交哈希，改用 git switch -c <新分支> <起点> 在创建分支的同时切换。若在标签上开发，先 git checkout -b <分支> <标签名>。
reflog 中记录的条目能区分是否来自 detached HEAD 吗？
可以。git reflog 的显示中，如果行动是 checkout: moving from <哈希> to <哈希> 或 commit: ...，结合当前状态可判断。但更直接的是看 HEAD@{n} 后的提交消息与实际操作，不必追究原始来源。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。