能恢复，但必须立刻行动——reflog默认保留30天，未触发git gc时可通过git reflog查找删除前的提交哈希，再用git branch重建分支；若reflog失效则用git fsck扫描dangling commit，或从远程同步恢复。
能恢复，但必须立刻行动——reflog 通常只保留 30 天，且一旦执行 git gc --prune=now 或长时间不操作，提交就可能永久丢失。
用 git reflog 找回刚删的分支
这是最快、最可靠的路径，前提是删除操作发生在近期（≤30 天），且没手动触发过垃圾回收。
- 运行
git reflog，逐行查看，重点找含branch: deleted或切换到目标分支前的那条记录（如HEAD@{3}） - 若记不清分支名，用
git reflog --all | grep "deleted"过滤；PowerShell 用户改用git reflog --all | sls "deleted" - 确认该条目对应的目标提交：运行
git show HEAD@{3}看作者、时间、提交信息是否匹配 - 重建分支：
git branch feature/login HEAD@{3}（不要用-f，除非同名分支已存在） - 注意：哈希值必须完整（至少 12 位），旧版 Git 解析短哈希（如
abc1234）可能失败
找不到 reflog 记录时，用 git fsck 扫游离提交
当 reflog 被清理、或你删分支后又做了大量其他操作，git fsck 是兜底手段，但需人工识别目标提交。
- 执行
git fsck --lost-found，输出中筛选dangling commit行（如dangling commit def5678） - 对每个可疑哈希运行
git log --oneline -n 3 def5678，比对时间、作者、文件变更 - 确认后创建分支：
git branch recovered-feature def5678 - 如果原分支有多个本地提交，而
fsck只找到末端一个，需用git cherry-pick向前补全，或检查.git/lost-found/commit/下的原始对象文件
远程分支还在？直接同步回来
只要没在远端执行 git push origin :branch-name，或平台（GitHub/GitLab）尚未自动清理（默认约 30 天），就能零成本恢复。
- 先刷新远程引用：
git remote update origin --prune - 检查是否存在：
git branch -r | grep branch-name - 本地重建并设置上游：
git checkout -b branch-name origin/branch-name - 注意：某些企业 Git 服务（如自建 GitLab）可能禁用 reflog 保留或缩短清理周期，不能默认远端一定还在
git show 报错 “not a valid object name” 怎么办
说明你手里的哈希已失效——不是输错了，就是它真被 GC 清掉了。别反复试，换策略。
- 立刻再跑一次
git reflog，看是否有邻近时间点的其他条目（如HEAD@{4}、HEAD@{5}） - 运行
git fsck --unreachable（比--lost-found更激进），找未被任何引用触达的提交 - 检查 stash：
git stash list，误删分支前如果git stash过，可能藏了关键状态 - 翻 tag 或其他分支：
git merge-base branch-name other-feature，有时目标提交还挂在别的分支上
真正难恢复的，是那种删完分支又连续执行了 git fetch --prune + git gc --prune=now 的情况——reflog 和 dangling 对象一并清空，连 fsck 都扫不出东西。这时候唯一指望，是同事本地有没有未推送的副本，或者 CI 构建缓存里有没有打包过的 commit 引用。
