能救回来，只要没执行 git gc --prune=now 且 reflog 还在（默认保留90天）——分支删除只是删指针，提交对象根本没动。
能救回来，只要没执行 git gc --prune=now 且 reflog 还在（默认保留90天）——分支删除只是删指针，提交对象根本没动。
用 git reflog --all 快速定位被删分支的最后提交哈希
这是最优先、最可靠的入口。只跑 git reflog 很可能漏掉目标，因为它默认只查当前分支的 HEAD 日志；而被删分支的操作记录藏在 reflog --all 里。
- 立即执行：
git reflog --all | grep "branch: deleted\|moving from.*your-branch-name"（把your-branch-name换成你删掉的分支名） - Windows 用户用：
git reflog --all | findstr "your-branch-name" - 看到类似
abc1234 HEAD@{5}: branch: deleted: refs/heads/feature/login或def5678 HEAD@{12}: checkout: moving from feature/login to main——前面那个哈希（abc1234或def5678）就是你要的 - 别急着建分支，先验证：
git show abc1234看作者、时间、改动文件是否符合记忆
用 git branch <name> <hash> 安全重建分支，别用 checkout -b
直接 git checkout -b 会强制切换工作区，如果当前有未暂存修改，容易触发冲突警告甚至覆盖风险；而 git branch 只建指针，干净可控。
- 执行：
git branch feature/login abc1234（abc1234替换为你确认过的哈希） - Git ≥ 2.23 可用更语义化的：
git switch -c feature/login abc1234，但本质一样 - 如果原分支有远程跟踪（如
origin/feature/login），建完后补一句：git branch --set-upstream-to=origin/feature/login feature/login - 重命名建议：若当前已有同名分支（比如大小写不同或已存在
feature/dev23），务必起新名（如feature/login-restore），避免覆盖或冲突
当 reflog 被清空或找不到记录时，用 git fsck --lost-found 扫描悬空提交
这是兜底手段，但效率低、结果杂——git fsck 默认不报刚删分支的提交，因为它们仍被 reflog 引用；只有 reflog 失效后，这些提交才变成 “dangling”。
- 先停所有写操作（连
git status都暂时别跑，某些配置下会触发 auto-gc） - 运行：
git fsck --lost-found，筛选输出中含dangling commit的行，例如：dangling commit def5678 - 对每个可疑哈希，快速检查：
git log --oneline -n 3 def5678，比对时间、作者、消息关键词 - 确认后执行：
git branch recovered-branch def5678 - 注意：如果要还原多个连续提交，
git cherry-pick是比反复建分支更实际的选择
远程分支其实还在？先同步再拉取，别本地重建
如果你曾推送过该分支，且远程端（GitHub/GitLab）没手动删它，这是最快最安全的路径——完全绕过本地恢复风险。
- 先同步远端引用：
git remote update origin --prune - 检查是否存在：
git branch -r | grep "origin/feature/login" - 如果显示
origin/feature/login，直接建本地分支并关联：git checkout -b feature/login origin/feature/login - 这个操作不会依赖本地 reflog 或对象数据库，只要远程还存着，就 100% 保真
真正危险的不是删分支本身，而是删完之后又执行了 git gc、长时间闲置、或者反复 git status 触发自动回收——这些会让原本可恢复的对象真正消失。reflog 是第一道防线，也是最容易被忽略的“黑匣子”，别等它过期才想起翻。
