能救回来，只要未执行git gc --prune=now且reflog仍在（默认保留90天）；优先用git reflog --all定位被删分支最后一次提交哈希，再用git branch安全重建分支。
git reflog --all 是恢复误删分支的第一入口
别只跑 git reflog，它默认只查当前分支的 HEAD 日志，而被删分支的操作记录基本都藏在 git reflog --all 里。你删分支时 Git 并没抹掉提交，只是移除了那个分支指针，而指针最后一次指向的位置，就记在 --all 的日志中。
立刻执行：git reflog --all | grep "feature/login"（Linux/macOS）或 git reflog --all | findstr "feature/login"（Windows）。输出中类似这样的行就是关键：abc1234 HEAD@{5}: checkout: moving from feature/login to main——开头的 abc1234 就是你要的提交哈希。
- 哈希必须复制完整（至少 12 位），旧版 Git 解析前 7 位可能失败
- 如果 grep 不到分支名，直接扫
checkout:或commit:行，按时间倒序找误删前几分钟的记录 - 别信
HEAD@{5}这种相对引用，粘贴进命令前先用git show abc1234验证内容是否匹配记忆
用 git branch 恢复比 git checkout -b 更安全
git branch feature/login abc1234 是重建分支最干净的方式。它只新建一个指针，不碰工作区、不触发切换、不干扰你当前未暂存的修改。而 git checkout -b 会强制切换并尝试合并当前状态，一旦有冲突或未暂存变更，容易卡住甚至覆盖。
- Git ≥ 2.23 可用
git switch -c feature/login abc1234，语义更清晰，但底层行为和git branch一致 - 如果原分支曾关联远程（如
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 --lost-found 不是首选，而是 reflog 被清空（比如执行过 git reflog expire --expire=now --all）后的最后选择。它扫描的是“不可达对象”，而刚删分支的提交通常仍被 reflog 引用，属于“可达但无分支名”，所以 fsck 默认不会报出来——只有 reflog 失效后，这些提交才变成 dangling commit def5678。
- 执行前先停所有 Git 操作，包括
git status（某些配置下会触发 auto-gc） - 运行
git fsck --lost-found，从输出中筛选dangling commit行 - 对每个可疑哈希运行
git log --oneline -n 3 def5678，比对作者、时间、消息关键词 - 确认后执行
git branch recovered-branch def5678；若需还原多个连续提交，git cherry-pick比反复建分支更实际
远程分支还在？优先同步，别本地重建
如果你之前推过该分支且远程没删，这是最快最稳妥的路径。本地重建再推回去，不仅多一步，还可能撞上远程分支保护策略（GitLab 常见），导致推送被拦截。
- 先同步远端引用：
git remote update origin --prune - 检查是否存在：
git branch -r | grep "origin/feature/login" - 如果看到
origin/feature/login，直接执行：git checkout -b feature/login origin/feature/login - 如果远程也没了（比如你执行过
git push origin :feature/login），再推回去：git push -u origin feature/login，漏掉-u后续git push会报 “no upstream configured”
reflog 默认保留 90 天，但前提是没执行 git gc --prune=now。发现误删后第一反应不是查文档，是立刻停手、跑 git reflog --all —— 拖得越久，风险越高。
