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