reflog 是恢复删除分支的第一入口，必须用 git reflog --all 查全局记录；找到形如 abc123456789 head@{5}: branch: deleted: refs/heads/feature/login 的行，提取至少 12 位哈希，再通过 git branch 或 git switch 创建分支。
reflog 是第一入口，必须用 git reflog --all
只跑 git reflog 很可能找不到目标——它默认只查当前分支的 HEAD 记录，而被删分支的操作藏在全局 reflog 里。
立刻执行：git reflog --all | grep "branch: deleted\|moving from your-branch-name"（把 your-branch-name 换成实际分支名）。
Windows 用户改用：git reflog --all | findstr "your-branch-name"。
重点找形如 abc123456789 HEAD@{5}: branch: deleted: refs/heads/feature/login 的行，前面那个哈希就是关键。
哈希至少要 12 位；短哈希如 abc1234 在 Git 2.20 之前版本大概率解析失败。
验证哈希再建分支，别用 git checkout -b
git checkout -b 会强制切换工作区，如果当前有未暂存修改，可能触发冲突警告甚至覆盖风险。
安全做法是只建指针：
• 运行 git show abc123456789 确认作者、时间、改动文件是否匹配记忆
• 执行 git branch feature/login abc123456789（不加 -f，除非同名分支已存在且你确定要覆盖）
• Git ≥ 2.23 可用 git switch -c feature/login abc123456789，语义更清，但本质一样
• 若原分支有远程跟踪（如 origin/feature/login），建完后补一句：git branch --set-upstream-to=origin/feature/login feature/login
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
reflog 找不到时，git fsck --lost-found 是兜底手段
git fsck 默认不报刚删分支的提交——因为它们仍被 reflog 引用，不算 “dangling”。只有 reflog 失效后，这些提交才真正游离。
操作前先停所有写操作（包括 git status，某些配置下会触发 auto-gc）
运行：git fsck --lost-found，筛选输出中含 dangling commit def56789abc 的行
对每个可疑哈希，快速检查：git log --oneline -n 3 def56789abc，比对时间、作者、消息关键词
确认后执行：git branch recovered-feature def56789abc
注意：如果要还原多个连续提交，git cherry-pick 比反复建分支更实际
容易被忽略的细节：大小写、reflog 条目位置、远程是否还在
reflog 条目可能存在于 HEAD@{n} 而非 refs/heads/xxx@{0}——尤其当分支名大小写不一致（如 feature/Dev23 vs feature/dev23）或已被清理时，得手动扫 git reflog --all 全量输出。
远程分支其实可能还在：先运行 git remote update origin --prune，再查 git branch -r | grep feature/login；若存在，直接 git switch -c feature/login origin/feature/login 最省事。
企业自建 GitLab 或某些 CI 配置可能禁用 reflog 保留或缩短清理周期，不能默认远端一定还在。
