如何恢复被误删的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 vs feature/dev23）或已被清理时，得手动扫 git reflog --date=iso 输出里的 checkout: 行。哈希一旦失效（git show 报 not a valid object name），别反复试，立刻切到 fsck 或检查远程是否存在。