git分支指针本质是.git/refs/heads/下存储sha-1哈希值的纯文本文件，仅在新提交时向前移动或通过git reset、git branch -f等显式命令强制重置，不会自然“向后”移动。
Git 分支指针不会“向后移动”——这是个常见误解。分支指针只会在新提交时向前移动，或通过 git reset、git branch -f 等显式命令被强制重置到更早的提交。所谓“向后”，其实是人为重写指针指向，不是 Git 自然行为。
分支指针的本质就是文件内容：一个 SHA-1 值
每个分支（如 main）对应 .git/refs/heads/main 这个纯文本文件，里面只存一行：40 位 SHA-1 哈希值，例如 961b8e2a3d...f0c7。这个值就是该分支当前指向的 commit 对象 ID。
所谓“移动”，就是用新哈希覆盖旧哈希。Git 不会删旧 commit，也不改历史链，只是改这个文件的内容。
-
git commit→ 计算新 commit 的 SHA-1 → 写入.git/objects/→ 把新哈希写进当前分支文件 -
git checkout feature→ 把HEAD文件内容改成ref: refs/heads/feature→ 读取.git/refs/heads/feature得到当前 commit -
git branch -f main abc123→ 直接覆写.git/refs/heads/main为abc123...，不涉及任何 commit 创建或删除
为什么不能靠“提交”让指针向后走？
提交操作永远生成新 commit，并让当前分支指针指向它——这是单向推进。Git 的 commit 链是单向的（每个 commit 记录 parent），没有“上一个 commit 的上一个”这种内置回溯机制。
想让分支指针回到过去某次提交，必须显式干预：
-
git reset --hard <commit-id></commit-id>：重写分支指针 + 暂存区 + 工作区 -
git branch -f branch-name <commit-id></commit-id>：只重写分支指针，不影响 HEAD 或工作区 -
echo "abc123..." > .git/refs/heads/main：手动编辑，效果等同于git branch -f
注意：git revert 不是“向后移动指针”，而是创建一个**新 commit**，内容是抵消目标 commit 的变更——指针依然向前走。
HEAD 和分支指针的关系容易混淆
HEAD 是一个符号引用（symbolic ref），通常内容是 ref: refs/heads/main；而 main 本身是普通引用（plain ref），内容是 SHA-1。
当你执行 git checkout main，Git 并不是“把 HEAD 移到 main”，而是：
- 把
HEAD文件内容设为ref: refs/heads/main - 读取
.git/refs/heads/main得到最新 commit ID - 把该 commit 的 tree 解包到工作区和暂存区
如果直接 git checkout abc123（非分支名），HEAD 就变成 detached，内容不再是 ref: ...，而是直接写入 abc123... ——此时它不再指向分支，而是直接指向 commit。
真正要小心的是：分支指针的重写不可逆（除非有 reflog），且 .git/refs/ 下的文件一旦被手动篡改，Git 不会校验其合法性。很多诡异的“分支消失”或“提交找不到”，源头就是误删或乱写这些指针文件。
