能恢复，只要未执行 git gc --prune=now 且 reflog 仍在（默认保留 30–90 天）；删除分支仅移除指针，提交对象未被删除；用 git reflog --all 查找被删分支最后提交哈希最可靠。
能恢复，只要没执行 git gc --prune=now 且 reflog 还在（默认保留 30–90 天）——删除分支只是删掉指针，提交对象本身根本没动。
用 git reflog --all 找被删分支的最后提交哈希
这是最快、最可靠的入口。只跑 git reflog 很可能漏掉目标，因为它默认只查当前分支的 HEAD 日志；而被删分支的操作记录藏在 --all 里。
- 立刻执行：
git reflog --all | grep "branch: deleted\|moving from your-branch-name"（把your-branch-name换成实际分支名） - Windows 用户用：
git reflog --all | findstr "your-branch-name"；macOS/Linux 用grep - 重点找形如
abc123456789 HEAD@{5}: branch: deleted: refs/heads/feature/login或def567890123 HEAD@{12}: checkout: moving from feature/login to main的行——前面那个哈希就是你要的 - 哈希必须完整（至少 12 位），旧版 Git 解析短哈希（如
abc1234）可能失败 - 别急着建分支，先验证：
git show abc123456789看作者、时间、改动文件是否匹配记忆
用 git branch 安全重建分支，别用 git checkout -b
git checkout -b 会强制切换工作区，如果当前有未暂存修改，容易触发冲突警告甚至覆盖风险；git branch 只建指针，干净可控。
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 执行：
git branch feature/login abc123456789（替换为确认过的哈希） - Git ≥ 2.23 可用更语义化的
git switch -c feature/login abc123456789，但本质一样 - 如果原分支有远程跟踪（如
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 默认不报刚删分支的提交，因为它们仍被 reflog 引用；只有 reflog 失效后，这些提交才变成 “dangling”。
- 先停所有写操作（连
git status都暂时别跑，某些配置下会触发 auto-gc） - 运行：
git fsck --lost-found，筛选输出中含dangling commit def5678的行 - 对每个可疑哈希快速检查：
git log --oneline -n 3 def5678，比对时间、作者、消息关键词 - 确认后执行：
git branch recovered-feature def5678 - 如果要还原多个连续提交，
git cherry-pick是比反复建分支更实际的选择
最容易被忽略的是：reflog 条目可能存在于 HEAD@{n} 而非 refs/heads/xxx@{0}——尤其当分支名大小写不一致（如 feature/Dev23 vs feature/dev23）或已被清理时，得手动扫 git reflog --all 输出逐行看。
