detached head 是 git 正常状态，指 head 直接指向 commit 而非分支；此时提交不归属任何分支，易被垃圾回收，需用 git switch -c 新分支保存或 git reflog 恢复。
Detached HEAD 是什么，为什么它不是错误
Detached HEAD 不是 Git 的异常状态，而是你当前 HEAD 直接指向某个 commit（而非分支名）时的正常行为。常见于 git checkout <commit-hash></commit-hash>、git checkout <tag-name></tag-name> 或从 CI 构建产物中检出特定提交时。
此时所有新提交会“悬空”——没有分支引用它们，一旦切换到其他分支，这些提交就难以找回（除非通过 git reflog）。
- 不会报错，但命令行提示会明确显示
(HEAD detached at a1b2c3d) -
git status仍显示 “On branch” —— 但后面是 commit hash，不是分支名 - 执行
git merge或git pull会失败，提示 “You are not currently on a branch”
如何安全地把当前 detached HEAD 提交保存为新分支
核心动作就是用 git switch -c <new-branch-name></new-branch-name> 或等价的 git checkout -b <new-branch-name></new-branch-name>。Git 会以当前 HEAD 指向的 commit 为起点，创建并切换到新分支。
注意：如果当前已有未提交的改动，Git 会原样带入新分支；如果已提交过若干次（即在 detached 状态下做了多次 git commit），这些提交都会成为新分支的历史。
- 推荐用
git switch -c feature/fix-from-tag（Git 2.23+），语义更清晰 - 避免用
git branch <name></name>单独创建再git checkout <name></name>，多一步且易忘切换 - 如果不确定当前 HEAD 位置，先运行
git log --oneline -n 5确认顶部 commit 是否是你想保留的起点
误操作后怎么找回丢失的提交
如果你在 detached HEAD 下提交了几次，然后切走了却没建分支，那些提交看似“消失”，其实还在对象数据库里，只是没被任何引用指向。
关键工具是 git reflog —— 它记录了 HEAD 的每次移动，包括 detached 状态下的 commit。
- 运行
git reflog，找到类似a1b2c3d HEAD@{0}: commit: fix login timeout的条目 - 复制对应 commit hash（如
a1b2c3d），用git switch -c rescue-branch a1b2c3d拉出分支 -
git reflog默认只保留 90 天或 50 条记录（取决于配置），超期后提交可能被git gc清理
哪些场景该主动进入 detached HEAD，哪些该立刻规避
detached HEAD 本身中性，问题在于是否意识到它的生命周期限制。适合它的地方是“只读快照访问”，不适合它的地方是“开发工作流”。
- ✅ 安全使用：验证某 tag 构建结果（
git checkout v1.2.3）、二分查找 bug（git bisect自动进入 detached）、CI 中 checkout 特定 commit - ❌ 风险操作：在
git checkout <commit></commit>后直接改代码 +git commit，却不建分支；或把 detached HEAD 当成临时分支长期工作 - ⚠️ 注意：
git checkout <remote>/<branch></branch></remote>（如origin/main）也会进入 detached HEAD —— 这是很多人意外触发的源头
真正容易被忽略的点是：detached HEAD 下的提交无法被 push 到远程，除非先建分支。而一旦忘记这步，换台机器或清理 reflog 后，那些改动就真没了。
