能恢复，只要未执行 git gc --prune=now 且 reflog 仍在（默认保留30–90天）；分支删除仅移除指针，提交对象仍存于 .git/objects 中，可通过 git reflog --all 查找被删分支的最后提交哈希并用 git branch 重建。
能恢复，只要没执行 git gc --prune=now 且 reflog 还在（默认保留 30–90 天）——分支删除只是删指针，提交对象仍完整躺在 .git/objects 里。
用 git reflog --all 找被删分支的最后提交哈希
别只跑 git reflog，它默认只查当前分支的 HEAD@{n}，而被删分支的操作记录藏在全局 reflog 里。
- Linux/macOS：运行
git reflog --all | grep "branch: deleted\|moving from feature/login"（把feature/login换成你的分支名） - Windows：用
git reflog --all | findstr "feature/login" - 重点识别形如
abc1234 HEAD@{5}: branch: deleted: refs/heads/feature/login的行，前面的abc1234就是目标哈希 - 注意大小写：如果分支名是
Feature/Login，但你搜feature/login，可能漏掉；reflog 条目可能存在于HEAD@{n}而非refs/heads/xxx@{0}
用 git branch 安全重建分支，别用 checkout -b
git checkout -b 会强制切换工作区，若当前有未暂存修改，可能触发冲突警告甚至覆盖风险；git branch 只建指针，零副作用。
- 验证哈希有效性：先运行
git show abc1234，确认作者、时间、改动文件符合记忆 - 重建命令：
git branch feature/login abc1234（哈希至少 12 位，旧版 Git 解析短哈希如abc1234可能失败） - Git ≥ 2.23 可用语义更清晰的
git switch -c feature/login abc1234，效果等价 - 若原分支有远程跟踪（如
origin/feature/login），补一句：git branch --set-upstream-to=origin/feature/login feature/login
reflog 找不到时，用 git fsck --lost-found 扫悬空提交
这是兜底手段，但效率低、结果杂——git fsck 默认不报刚删分支的提交，因为它们仍被 reflog 引用；只有 reflog 失效后，这些提交才变成 dangling commit。
- 立即停所有写操作（连
git status都暂时别跑，某些配置下会触发 auto-gc） - 运行
git fsck --lost-found，筛选输出中含dangling commit def5678的行 - 对每个可疑哈希快速检查：
git log --oneline -n 3 def5678，比对时间、作者、消息关键词 - 确认后执行：
git branch recovered-feature def5678 - 如果原分支有多个本地提交，而
fsck只找到末端一个，得靠git cherry-pick向前补全
最容易被忽略的是：reflog 条目可能因大小写差异或分支名拼写误差而难以匹配；另外，git show 报 "not a valid object name" 不是输错了，而是哈希真被 GC 清掉了——这时候别反复试，该切策略就切。
