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