能找回，只要未执行 git gc --prune=now 或闲置超90天，删除分支仅移除指针，提交对象仍存在；优先用 git reflog --all 定位最后提交哈希，再 git branch 重建分支。
能找回，只要没执行 git gc --prune=now 或闲置超 90 天，被删分支的提交对象基本都还在。 分支删除只是移除了指向提交的指针，不是删提交本身。关键在立刻行动，别等 reflog 过期或对象被回收。
用 git reflog --all 快速定位最后一次提交哈希
reflog 是最优先、最可靠的恢复入口，它记录所有引用变更，包括 checkout、merge、branch 删除前的状态。
- 立刻运行
git reflog --all（不用git reflog，避免只查当前分支漏掉目标） - 在输出里搜分支名、关键词如
checkout: moving from feature/login to main，那行前面的哈希（如abc1234）就是该分支最后指向的提交 - Windows 用户用
git reflog --all | findstr "feature/login"；macOS/Linux 用git reflog --all | grep "feature/login" - 确认哈希有效：运行
git show abc1234，看作者、时间、文件变更是否匹配你记得的内容
用 git branch 重建分支，别用 checkout -b 冲突工作区
拿到哈希后，重建分支要干净、可控，避免意外切换或覆盖当前修改。
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 直接执行
git branch feature/login abc1234—— 这只是创建指针，不改变工作区状态 - 不要用
git checkout -b feature/login 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 扫描悬空提交
这是兜底手段，但效率低、结果杂，只在 reflog 失效后启用。
- 先停掉所有写操作（包括
git status，某些配置下会触发 auto-gc） - 运行
git fsck --lost-found，筛选出dangling commit def5678类型的行 - 对每个可疑哈希运行
git log --oneline -n 3 def5678，比对提交信息和时间范围 - 确认后执行
git branch recovered-branch def5678；若需还原多个提交，得靠git cherry-pick或git replace补链 - 注意：
git fsck默认不报刚删分支的提交——因为它们仍被 reflog 引用，属于“可达但无分支名”，不是 dangling
远程分支还在？直接同步，别本地重建再推
如果分支曾推送到远程且未被远程端清理，这是最快最安全的路径，完全绕过本地恢复风险。
- 先同步远端引用：
git remote update origin --prune - 检查是否存在：
git branch -r | grep "origin/feature/login" - 存在就直接拉取并建立本地分支：
git checkout -b feature/login origin/feature/login - GitHub 用户可去 Settings → Branches → Deleted branches 页面一键还原（30 天内）；GitLab 用户注意保护分支策略可能拦截推送，需临时关闭
最容易被忽略的是 reflog 的时效性与对象存活状态的分离：reflog 条目默认 30 天过期（合并提交）或 90 天（普通提交），但提交对象本身只要没被 git gc 清理，就一直躺在 .git/objects 里。所以即使 git reflog 看不到记录，git fsck 仍可能扫出提交——前提是别让仓库继续写入触发自动回收。
