git checkout 和 git switch 切换分支时，只修改 .git/HEAD 文件内容使其指向新分支引用（如 refs/heads/feature），不复制文件；工作目录更新是根据目标分支所指 commit 还原快照的副作用，而非切换本质。
Git 分支不是“副本”，而是指向某次提交的轻量级指针；HEAD 也不是分支本身，而是你当前“站在哪”的标记——理解这点，才能避免误操作丢 commit、切错分支后找不到代码、或合并时出现诡异冲突。
git checkout 和 git switch 切换分支时，到底改了什么？
它们只修改 .git/HEAD 文件的内容，让 HEAD 指向新的分支引用路径（比如从 ref: refs/heads/main 变成 ref: refs/heads/feature），不复制文件、不重建索引。
- 工作目录内容随之更新，是因为 Git 根据新分支指向的 commit，还原对应快照 —— 这是 checkout/switch 的副作用，不是“切换”的本质
- 如果当前有未暂存的修改，且目标分支在相同路径下有不同内容，Git 会拒绝切换，报错
error: Your local changes to the following files would be overwritten by checkout -
git switch是 Git 2.23+ 推出的替代命令，语义更清晰；git checkout仍可用，但混用-b、--detach等参数容易误触发 detached HEAD
为什么 git commit 后，只有当前分支指针移动，其他分支不动？
因为 commit 的本质是：生成新对象 → 把当前分支的引用文件（如 .git/refs/heads/main）内容替换成新 commit 的 SHA-1 哈希值。HEAD 只是“告诉 Git 往哪写”，真正被修改的是那个分支文件。
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
- 分支文件（如
.git/refs/heads/feature）里只存一行哈希，比如961b8c7a2f4d5e6b0a1c2d3e4f5a6b7c8d9e0f1a - HEAD 指向该分支时，commit 才会自动推进分支指针；若 HEAD 处于 detached 状态（即直接指向 commit），则 commit 后不会更新任何分支指针，新 commit 成为“游离节点”
- 执行
git branch -f feature HEAD~2可强制把feature分支指针移到任意 commit，但要注意这会丢失中间提交的可达性（除非有其他引用指向它们）
detached HEAD 状态下提交，commit 去哪了？
它真实存在，只是没有分支指针指向它 —— 所以 git log 默认看不到，git gc 在一定时间后可能回收它。
- 用
git reflog能查到所有 HEAD 移动历史，包括 detached 下的 commit，这是找回它的主要途径 - 想保留这些提交？立刻运行
git branch recovery-branch（不带参数），Git 会在当前 HEAD 创建新分支，指向这个游离 commit - 不要长期在 detached HEAD 下开发；CI/CD 流程中若用
git checkout <commit-hash>构建，务必确认是否需要打标签或建临时分支，否则上线后可能无法追溯
git branch -f 重置分支指针的风险点
它绕过 Git 的“向前推进”默认策略，直接覆写分支引用文件 —— 快速但危险，尤其当目标 commit 不在当前分支祖先链上时。
- 执行
git branch -f main origin/main可强制同步本地main到远程最新，但若本地有未推送的 commit，这些 commit 将失去分支引用，变成 dangling commit - Git 不会警告你“将丢失 N 个 commit”，它只默默改文件；建议先用
git merge-base main origin/main检查是否有分叉 - 团队协作中慎用
-f，除非你明确知道后果并已沟通；git reset --hard更常用，但它同时重置工作区和暂存区，而git branch -f只动指针
分支指针和 HEAD 的分离设计，是 Git 高效与灵活的根基，但也意味着所有“看不见的指针移动”都可能带来不可逆影响。最常被忽略的，是以为 git checkout <hash> 只是“看看旧代码”，却没意识到自己已经脱离分支轨道——那之后的每一次 commit，都在无人认领的角落独自存在。
