能恢复，但窗口期极短——reflog默认保留30天，一旦执行git gc --prune=now或长时间闲置，提交可能永久丢失；需立即用git reflog --all查找被删分支最后一次提交哈希，确认后执行git branch重建分支。
能恢复，但窗口期极短——reflog 默认只存 30 天，且一旦执行 git gc --prune=now 或长时间闲置，提交就可能永久消失。
用 git reflog 找刚删分支的最后一次提交
这是最快、最常用的方法，前提是删除操作发生在近期（≤30 天），且没手动触发垃圾回收。
- 立刻运行
git reflog --all，不要只用git reflog（后者只显示当前分支的 HEAD 记录，容易漏掉目标） - 在输出里搜分支名、关键词
checkout: moving from feature/login to或branch: deleted；Windows PowerShell 用户用git reflog --all | sls "feature/login"，macOS/Linux 用git reflog --all | grep "feature/login" - 找到对应行后，记下那一列的完整提交哈希（如
abc123456789），至少 12 位；短哈希（如abc1234）在旧版 Git 中可能解析失败 - 用
git show abc123456789确认作者、时间、变更文件是否匹配你记忆中的最后一次提交
用 git branch 重建分支，别用 git checkout -b
确认哈希无误后，重建分支是纯引用操作，不改变工作区，更安全。
- 执行
git branch feature/login abc123456789（把feature/login换成原分支名），不要加-f，除非同名分支已存在且你确定要覆盖 - 避免用
git checkout -b feature/login abc123456789：它会立即切换并可能覆盖未暂存的修改，干扰当前开发状态 - 如果原分支有远程跟踪分支（如
origin/feature/login），重建后需手动关联：git branch --set-upstream-to=origin/feature/login feature/login - 验证是否成功：
git branch --contains abc123456789应列出新分支名
reflog 没记录？试试 git fsck --lost-found 扫悬空提交
reflog 被清理、或你删分支后又做了大量其他操作（如多次 rebase），git fsck 是兜底手段，但得人工筛。
- 运行
git fsck --lost-found，输出中找形如dangling commit def56789abc的行 - 对每个可疑哈希运行
git log --oneline -n 3 def56789abc，比对时间、作者、提交信息 - 确认后执行
git branch recovered-feature def56789abc - 注意：
git fsck默认不报“被删分支的提交”，因为它们仍被 reflog 引用；只有 reflog 失效后，这些提交才变成“不可达”，fsck 才能扫到
远程分支还在？直接同步回来最省事
只要没在远端执行 git push origin :feature/login，或 GitHub/GitLab 尚未自动清理（默认保留约 30 天），就能零成本恢复。
- 先同步远程引用：
git remote update origin --prune - 检查是否存在：
git branch -r | grep feature/login，若输出origin/feature/login，说明远端还在 - 本地恢复：
git checkout -b feature/login origin/feature/login或git switch -c feature/login origin/feature/login（Git 2.23+） - GitHub 用户可直奔 Settings → Branches → Deleted branches 页面一键还原（限 30 天内）；GitLab 若启用了保护策略，恢复前需临时关闭
真正容易被忽略的点是时间敏感性：reflog 不是永久日志，它按天衰减，且 git gc 可能随时触发。很多团队误删后等“忙完手头活再处理”，结果两天后发现 git reflog 里已找不到那条记录——不是命令失效，是对象真没了。
