能恢复，只要没执行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 或检查远程是否存在。
