能恢复，只要reflog未被清理（默认保留90天）且未执行git gc --prune=now；关键步骤是运行git reflog --all定位被删分支最后一次提交哈希，再用git branch重建分支。
能恢复，只要没执行过 git gc --prune=now 且 reflog 还在（默认保留 90 天），误删的分支几乎总能找回来——关键不是“怎么配 Linux”，而是用对 git reflog 和对应恢复命令。
怎么快速定位被删分支最后一次提交的哈希
reflog 记录的是 HEAD 移动历史，不是分支名本身。被删分支的最后一次提交，往往藏在 checkout: moving from feature/login to main 这类行里。
- 立刻运行
git reflog --all，比git reflog更全，避免只看当前分支漏掉目标 - 如果记得分支名，直接过滤：
git reflog --all | grep "feature/login"（Linux/macOS）或git reflog --all | findstr "feature/login"（Windows PowerShell） - 找不到分支名？扫
checkout:或commit:行，重点关注时间戳靠近误删操作前几分钟的条目，开头那串短哈希（如abc1234）就是关键 - 别信前 7 位哈希——某些旧 Git 版本解析失败，复制完整哈希（或至少 12 位）再用
用 reflog 哈希重建分支时为什么报 “not a valid object name”
这个错误说明你粘贴的哈希已失效，不是命令写错了，而是对象可能被清理或 reflog 条目过期了。
- 先验证哈希是否还活着：
git show abc1234，如果报错fatal: bad object abc1234，说明它已不可达 - 换一个 reflog 里相近时间点的哈希再试，比如从
HEAD@{3}换成HEAD@{5} - 如果 reflog 全空，说明被手动清理过（比如执行过
git reflog expire --expire=now --all），这时得切到git fsck --lost-found模式 - 注意：
git branch -f feature/login abc1234中的-f只在分支已存在时强制重设，新恢复不用加-f，直接git branch feature/login abc1234即可
恢复后怎么同步到远程仓库（尤其已推过原分支）
本地重建分支只是第一步；如果原分支曾推送到远程，还得让它重新上线，否则别人拉不到。
- 先确认远程是否还存着该分支：
git remote update origin --prune，再git branch -r | grep feature/login，如果看到origin/feature/login，说明远端没删，直接git checkout -b feature/login origin/feature/login就行 - 如果远端也没了（比如你执行过
git push origin :feature/login），那就得推回去：git push origin feature/login - 别漏
-u：git push -u origin feature/login，否则后续git push会报 “no upstream configured” - 如果原分支在远程被保护（GitLab 常见），推送前得临时关闭分支保护策略，否则会被拦截
reflog 不见了，还能靠 git fsck 找回来吗
能，但它是“最后手段”，效率低、结果难定位，而且成功率取决于 git gc 是否已运行。
-
git fsck --lost-found输出里找dangling commit def5678这类行，每个都是潜在目标 - 挨个看：
git show def5678，比对作者、时间、提交信息、变更文件，确认是不是你要的分支头 - 找到后，
git branch recovered-branch def5678新建分支指向它 - 注意：
git fsck默认不显示刚删分支的提交——因为它们仍被 reflog 引用，属于“可达但无分支名”，所以 reflog 没了才轮到它上场
真正容易被忽略的点是：reflog 是纯本地的，不会同步、不能推送、也不受远程影响；但它的生命周期依赖你有没有手动触发 git gc。发现误删后第一件事不是查文档，是立刻停手、别执行任何新 commit/reset/fetch，然后直奔 git reflog --all —— 越快越稳。
