Git本地分支索引损坏典型表现为断电后git status报错、卡死，或提示fatal: unable to read tree HEAD^{tree}等；应先删.git/index并git read-tree重建，再用git update-ref修复ref，避免使用依赖索引的git reset或git checkout。
Git本地分支索引损坏的典型表现
断电后 git status 报错、卡死，或提示类似 fatal: unable to read tree HEAD^{tree}、error: bad object HEAD、fatal: index file smaller than expected。这些不是远程问题，而是本地 .git/index</code 文件损坏——它记录了暂存区状态，Git多数操作（包括切换分支、提交、diff）都依赖它。
<p>这类损坏通常不波及对象数据库（<code>.git/objects/
），所以历史提交和文件内容大概率完好，重点是重建索引，而非恢复丢失数据。
用 git read-tree 快速重建干净索引
git read-tree 是 Git 内部命令，能直接从某个树对象加载索引，绕过已损坏的 .git/index。最安全的起点是当前分支的 HEAD：
git read-tree 是 Git 内部命令，能直接从某个树对象加载索引，绕过已损坏的 .git/index。最安全的起点是当前分支的 HEAD：
执行以下命令：
rm -f .git/index git read-tree HEAD
之后运行 git status 应该能正常响应，并显示“working tree clean”或准确的修改状态。
- 如果当前分支已不可达（比如
HEAD指向无效引用），改用具体分支名：git read-tree refs/heads/main - 若连
HEAD都读不出，可先用git fsck --no-reflog找出最近可用的 commit hash，再git read-tree <commit-hash> - 此操作不会重置工作区，也不会丢弃未暂存的修改——它只重建暂存区快照
分支指针本身损坏怎么办？
如果 git branch 列不出任何分支，或 cat .git/HEAD 显示乱码、空内容，说明分支引用（ref）也受损。此时不能只重建索引，还要修复 HEAD 和当前分支指向：
先确认当前想恢复的分支名（如 main），然后手动写入：
echo "ref: refs/heads/main" > .git/HEAD git update-ref refs/heads/main <commit-hash>
其中 <commit-hash> 可通过 git fsck --no-reflog | grep commit | head -1 获取最新提交哈希。注意：不要用 git reset，它会依赖已有索引，此时可能失败。
-
git update-ref是底层安全写 ref 的方式，比直接编辑.git/refs/heads/<branch>更可靠 - 如果原分支有未推送的提交，它们仍存在于对象库中，只是 ref 指针断了——
git fsck --unreachable可辅助定位 - 修复后立即运行
git status和git log -n 3验证分支位置是否正确
为什么不用 git checkout 或 git switch？
这两个命令在索引损坏时往往直接报错退出，因为它们内部会调用 git read-tree，但附带一堆校验和前置检查。而手动调用 git read-tree 绕过了这些依赖损坏索引的检查步骤，属于“最小可行恢复”。
另外，git reset --hard 在索引损坏时同样不可靠——它需要先读取索引才能决定哪些文件要重置，容易陷入死循环或误删工作区文件。
- 优先级顺序：先
rm .git/index+git read-tree→ 再修 ref → 最后验证工作区 - 别急着
git clone新仓库——90% 的情况，原始.git/objects/完好，重clone反而丢掉未推送的本地提交 - 真正危险的是
.git/index和.git/refs/同时损坏且无 reflog，但即使如此，git fsck --full仍常能捞回孤立提交
