git checkout -b 在游离状态下能保留修改，是因为它创建新分支指针并立即切换 HEAD 指向当前 commit，使此前的暂存和提交获得分支引用，避免成为孤立提交；而 git branch 仅创建引用却不切换 HEAD，仍处于游离状态。
游离状态下 git checkout -b 为什么能保留修改
因为 git checkout -b new-branch 并不是“把当前修改复制过去”，而是让新分支的指针直接指向当前 HEAD 所在的 commit，同时把 HEAD 切换到这个新分支上。此时你之前在游离状态做的 git add 和 git commit，只要没被 GC 清理，就立刻有了分支引用，不再是“匿名提交”。
关键点在于：分支创建动作本身不改变工作区和暂存区，只新增一个指向当前 commit 的引用，且重置 HEAD 指向该引用。
-
HEAD原本直接指向某个 commit（比如a1b2c3d），处于游离状态 -
git checkout -b fix-legacy会在.git/refs/heads/fix-legacy写入a1b2c3d，并把.git/HEAD改为ref: refs/heads/fix-legacy - 后续
git commit就会正常推进fix-legacy分支指针，而不是生成孤立提交
为什么不能直接 git branch new-branch 就完事
git branch new-branch 确实会创建分支，但它不会移动 HEAD；HEAD 仍处于游离状态，你接下来的 git commit 还是会生成无分支指向的提交——除非你手动再 git checkout new-branch。
换句话说：git branch 只建引用，git checkout -b 是建引用 + 切 HEAD，二者行为差一步，而这一步决定你是否真正“落地”。
- 执行
git branch temp后，git status依然显示HEAD detached at a1b2c3d - 执行
git checkout -b temp后，git status显示On branch temp - 若已用
git branch创建了分支，补救只需git checkout temp，无需额外操作
git reflog 在游离状态恢复中的真实作用
git reflog 不是用来“找回丢失代码”的，而是帮你定位那个游离 commit 的 SHA-1 ——尤其当你没记下它，又切走了分支，导致 git log 看不到那次提交时。
它的输出里每一行都是 HEAD@{N} 记录，其中 HEAD@{0} 是最近一次 HEAD 移动（通常是刚切走的分支），HEAD@{1} 往前推才是游离时的位置。你得靠它找到对应 commit ID，才能 git checkout 回去或 git merge 进来。
-
git reflog输出中类似a1b2c3d HEAD@{1}: checkout: moving from main to a1b2c3d表明游离起点 - 若游离后还做了提交，
HEAD@{0}可能已是新 commit，需看HEAD@{2}或更早 -
git reflog expire --expire=now --all会清空它，所以别等太久才查
远程分支 checkout 导致游离的典型陷阱
执行 git checkout origin/feature 必然触发游离，因为 origin/feature 是远程跟踪分支（只读），Git 不允许直接在其上提交。很多人误以为这是“切换到 feature 分支”，其实只是取了它的最新 commit 来检出。
正确做法永远是：用 git checkout -b feature origin/feature 或 git switch -c feature --track origin/feature，让本地分支建立跟踪关系，避免游离。
-
git branch -r查看远程分支列表，git branch -a才能看到全部（含远程） -
origin/xxx开头的分支名不能直接提交，只能作为创建本地分支的起点 - Git 2.23+ 推荐用
git switch -c xxx --track origin/xxx替代老旧的checkout -b语法
HEAD detached at，第一反应不是继续改代码，而是先 git checkout -b 落地。 
