Git 分离 HEAD（detached HEAD）状态如何与 master/origin 同步
detached HEAD 下做了改动先 git switch -c 新分支 保存成果，再切回 master 合并；没做改动直接 git switch master 即可。本文覆盖三种意图的完整操作。
一句话回答：先想清楚"分离 HEAD 期间有没有做过要保留的提交"：有——git switch -c temp-branch 立刻建分支保住它们，再切回 master 合并；没有——直接 git switch master（或 git switch -）回到正常分支状态即可，分离 HEAD 本身无害。
什么是分离 HEAD
正常状态下 HEAD 指向分支（分支再指向提交）；分离 HEAD 是 HEAD 直接指向某个提交，不经过任何分支。触发场景：
git checkout <提交哈希>查看历史版本git checkout v1.0（检出标签）- rebase、bisect 过程中
git status 会显示 HEAD detached at abc1234。
若 git status 显示 rebase/bisect 仍在进行，先按原操作的继续或中止流程处理，不要直接套用下面的切分支流程。下例 master 请替换成项目实际目标分支。
为什么危险：分离 HEAD 上的新提交不属于任何分支，一旦切走，这些提交变成"孤儿"，GC 后彻底丢失。
情况一：做了要保留的改动
# 1. 立刻建分支保住当前位置（未提交的改动会跟着走，已提交的也被分支钉住）
git switch -c my-fix
# 2. 有未提交改动就先提交
git status
git add -- path/to/intended-file
git diff --cached
git commit -m "在分离 HEAD 上的修复"
# 3. 切回 master 并合并
git switch master
git pull --ff-only # 若分叉则停止，另行评估合并
git merge my-fix
git push origin master
情况二：只是看看，没做任何改动
git switch master # 或 git switch - （回到上一个分支）
干净走人，什么都不用做。
情况三：做了改动但决定不要了
先用 git status、git diff 和 git diff --cached 核对范围。建议先给当前位置建一个救援分支，未提交内容另存备份或 git stash -u，再切回目标分支。普通 git switch master 会携带可兼容的改动，冲突时才拒绝，并非总会警告。
git switch --discard-changes master 会丢弃索引和工作区的已跟踪改动，只应在确认无需保留后使用；它不是清除所有未跟踪文件的命令。不要依赖垃圾回收帮你保管分离 HEAD 的提交。
预防：检出历史时的正确姿势
git switch -c 分支名 <提交> # 直接在新分支上查看历史
git switch --detach <提交> # 明确声明"我知道要分离"
常见问题（FAQ）
Q：已经切走了，分离 HEAD 上的提交还能找回吗？
A：可能，只要目标对象仍存在；reflog 保留与 GC 配置不同，没有保证可恢复的固定 30 天。git reflog 找到那个提交哈希，然后 git branch rescued <哈希> 建分支钉住它。
Q：git pull 在分离 HEAD 下会怎样？
A：未显式指定远程和分支的普通 pull 通常会因当前不在分支上而报错；显式指定后可能更新分离 HEAD，但仍不会替你创建本地分支。所以先建分支再 pull，别在分离状态下做同步。
Q：为什么 CI 系统里经常是分离 HEAD？
A：CI 按提交哈希检出代码（要测的是"这个提交"而不是"这个分支"），分离 HEAD 是刻意的正常状态，跑完丢弃即可，无需处理。
核查依据
本文依据官方文档核对，示例未在实际业务环境运行；上线前请按部署版本、权限与数据范围验证。
