如何恢复误删的Git本地分支详细步骤

能恢复，只要未执行 git gc --prune=now 或分支闲置未超过 30–90 天，被删除分支的提交记录通常仍留存；应立即运行 git reflog --all 定位包含“branch: deleted”或“checkout: moving from”的行，提取其前方哈希值并验证，再通过 git switch -c 重新创建分支。

先明确几个核心判断：只要没有执行 git gc --prune=now，或者分支闲置时间未超过 30–90 天，被删分支的提交对象通常仍然存在。关键就是一个字——快，立即查询 reflog，别等记录过期后再后悔莫及。

使用 git reflog --all 找到最后一次提交哈希

reflog 是最优先、最可靠的恢复手段，没有之一。它记录所有引用变更，包括 checkout、merge，甚至 branch -D 前的状态。不依赖远程仓库，纯本地操作，默认保留 30–90 天，这个窗口期足够你做出反应。

• 立即执行 git reflog --all，不要用 git reflog，后者仅查询当前分支，容易遗漏目标。
• Windows 用户可运行 git reflog --all | findstr "feature/login"；macOS/Linux 则使用 git reflog --all | grep "feature/login"。
• 重点查找包含 branch: deleted 或 checkout: moving from feature/login to main 的行。该行前面的哈希（如 abc1234）就是分支最后指向的提交。
• 确认哈希有效性：运行 git show abc1234，检查作者、时间、文件变更是否与你的记忆相符。

使用 git branch 重建分支，避免 checkout -b 干扰工作区

获取哈希后，重建分支应当干净、可控，防止意外切换或覆盖当前修改。

• 不要使用 git checkout -b feature/login abc1234，它会强制切换并可能触发未暂存文件的冲突警告。
• Git ≥ 2.23 推荐用语义更清晰的 git switch -c feature/login abc1234。
• 若原分支有远程跟踪（如 origin/feature/login），创建后手动执行 git branch --set-upstream-to=origin/feature/login feature/login。
• 哈希必须完整（至少 12 位），旧版 Git 解析短哈希（如 abc1234）可能失败。

reflog 找不到时，用 git fsck --lost-found 扫描悬空提交

这是最后的兜底方法，但效率低、结果杂乱，仅在 reflog 失效后才启用。注意：git fsck 默认不会报告刚删除分支的提交——因为它们仍被 reflog 引用，属于“可达但无分支名”，并非 dangling。

• 先停止所有写操作，包括 git status，某些配置下可能触发 auto-gc。
• 运行 git fsck --lost-found，筛选出 dangling commit def5678 类型的行。
• 对每个可疑哈希运行 git log --oneline -n 3 def5678，比对提交信息和时间范围。
• 确认后执行 git branch recovered-branch def5678；若需要还原多个提交，需借助 git cherry-pick 或 git replace 补全链条。

最容易忽略的是：reflog 条目可能存在于 HEAD@{n} 而非 refs/heads/xxx@{0} ——尤其在分支名大小写不一致（如 feature/Dev23 与 feature/dev23）或已被清理时，需要手动扫描 git reflog --date=iso 输出中的 checkout: 行。哈希一旦失效（git show 报 not a valid object name），不要反复尝试，立即转向 fsck 或检查远程仓库是否存在。