git update-ref 是唯一能直接写入分支指针的命令，支持精确指定 sha-1/sha-256 哈希，不依赖引用解析；必须用完整 ref 路径（如 refs/heads/main），默认不触发钩子也不记录 reflog，需 -m 才留痕，且不校验对象存在性。
update-ref 修改分支指向时，为什么 git branch -f 不够用？
当需要把分支精确重置到某个特定 commit（比如一个已删除的 reflog 条目、一个 detached HEAD 下的提交、或一个其他仓库里复制过来的哈希），git branch -f 会失败——它只接受当前仓库中能被解析为 commit 的引用（如 HEAD~3、origin/main），不支持直接传入 40 位 SHA-1 或 SHA-256 哈希字符串。而 git update-ref 绕过所有解析逻辑，直写 refs/heads/ 分支文件，是唯一可靠方式。
怎么用 update-ref 安全地移动分支指针？
基本命令格式是：git update-ref refs/heads/<branch-name><commit-hash></commit-hash></branch-name>。注意三点：
- 必须写完整 ref 路径
refs/heads/main，不能简写成main，否则会创建一个同名的 symbolic-ref 或失败 -
<commit-hash></commit-hash>必须是完整的 40 字符 SHA-1（或 64 字符 SHA-256），Git 不做校验，输错就真写错，且不会报错 - 如果目标分支当前是 HEAD，Git 不会自动更新
HEAD文件，工作区也不会变；需额外git checkout或git switch
示例：把 dev 分支强制指向已知提交 a1b2c3d...：
git update-ref refs/heads/dev a1b2c3d4e5f67890123456789012345678901234
update-ref 会触发钩子吗？会影响 reflog 吗？
默认情况下，git update-ref 不记录 reflog（即 git reflog 看不到这次移动）。如果要保留历史痕迹，必须显式加 -m 参数：
git update-ref -m "reset dev to hotfix commit" refs/heads/dev a1b2c3d...
它也不触发 pre-update 或 post-update 钩子——这些钩子只对通过 git push 或 git receive-pack 改 ref 的场景生效。本地手动 update-ref 是“绕过 Git 事务层”的操作，既快也危险。
误操作后如何快速恢复？
只要 reflog 还没被 git gc 清理，就能找回旧位置：
- 查该分支最近几次变更：
git reflog show dev - 恢复到上一次：
git update-ref refs/heads/dev dev@{1} - 或者用更安全的
git reset --hard dev@{1}（前提是dev当前是 HEAD）
但要注意：dev@{1} 是 reflog 别名，不是 commit hash，update-ref 不支持这种语法；必须先用 git rev-parse dev@{1} 解出真实哈希再传给 update-ref。
真正容易被忽略的是：update-ref 不检查目标 commit 是否存在于当前对象库——如果传入一个根本不存在的哈希，ref 文件照样被写入，后续 git log dev 会直接报错 fatal: bad object ...，而且这个错误不会在写入时暴露。
