能修，关键看远端分支引用是否仍存在：若 github/gitlab 页面或 git ls-remote 显示分支存活，仅需 git checkout -b branch-name origin/branch-name 重建；若远端已删但本地有提交，直接 git push origin branch-name 即可恢复；仅当本地和远端均消失时，才需通过 reflog 或 git fsck 抢救 dangling commit。
能修，但得看远端是否还存着分支引用——Git 本身不删提交，只删 ref；只要 origin/branch-name 还在本地引用缓存里、或远端仓库没清理、或 GitHub/GitLab 的 PR 记录还在，就能零成本拉回来。
git remote update origin --prune 后 origin/branch-name 消失了怎么办
这不是远端真没了，是本地缓存被清掉了。Git 默认不会自动同步远端所有分支引用，--prune 只是把本地已知但远端不存在的 origin/* 条目删掉，但远端分支本身可能毫发无损。
- 先确认远端是否真删了：直接打开 GitHub/GitLab 页面，进仓库 → Branches 标签页，搜分支名；或者用 API：
curl -s "https://api.github.com/repos/OWNER/REPO/branches" | jq '.[].name' - 如果页面上还能看到该分支，说明只是本地缓存断连，运行
git ls-remote --heads origin branch-name—— 如果返回一串哈希，证明远端 ref 还在 - 此时不用恢复，直接重建跟踪分支：
git checkout -b branch-name origin/branch-name（Git ≥ 2.23 可用git switch -c branch-name --track origin/branch-name） - 若
ls-remote无输出，再查 CI/CD 日志、团队成员本地是否有git branch -r | grep branch-name，有人推过就还有救
git show origin/branch-name 报错 “unknown revision”
说明本地已彻底丢失该远程引用，但远端未必消失。这个错误只代表你本地的 .git/FETCH_HEAD 或 refs/remotes/origin/branch-name 文件没了，不是远端 commit 被删了。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 别急着跑
git fsck，先刷新远端视图：git remote set-url origin <url></url>（确保 URL 没被意外改错），再执行git remote update origin（不带--prune） - 仍不行？手动试探远端是否存在：
git ls-remote origin refs/heads/branch-name—— 返回哈希即表示远端 ref 存活 - 若返回空，但你知道它最近被推送过，检查 Git 服务设置：GitHub 默认保留删除的分支引用 30 天；GitLab 社区版默认 30 天，企业版可配置为 7 天甚至更短；自建服务可能禁用 reflog 保留
- 某些平台（如 Azure DevOps）会把 PR 关联的分支单独保留，即使主 ref 被删，也能从 PR 页面点 “View merge commit” 找到对应 commit 哈希
远端分支真被删了，但本地还有提交记录
这是最省心的情况：你本地分支没删，只是远端没了。Git 推送时会重建远端 ref，不需要“恢复”，只需重推。
- 确保当前在该分支上：
git checkout branch-name（或git switch branch-name） - 直接推上去：
git push origin branch-name—— Git 会在远端创建同名分支并设为起点 - 如果之前设过上游，但推送失败提示 “non-fast-forward”，说明远端有冲突历史（比如别人重写了该分支），加
--force-with-lease更安全：git push --force-with-lease origin branch-name - 若该分支曾关联 PR/MR，重推后记得去平台重新激活或更新链接，部分系统不会自动识别“同名新分支”为原 PR 的延续
远端和本地分支都消失了，只剩 reflog 或 dangling commit
这时候才真正进入“数据抢救”阶段。reflog 是第一道防线，git fsck 是最后兜底，但两者都依赖对象未被 git gc 清理 —— 当前时间是 2026 年 5 月，如果你最后一次操作在 2 个月前，且没触发过 git gc --prune=now，大概率还能捞。
- 立刻运行：
git reflog --all | grep -i "branch-name\|deleted"（macOS/Linux）或git reflog --all | findstr /i "branch-name deleted"（Windows） - 找到类似
abc1234 HEAD@{5}: branch: deleted的行，用git show abc1234确认内容；匹配后执行git branch branch-name abc1234 - reflog 空了？试
git fsck --unreachable --no-reflogs | grep commit，挑出哈希后用git log --oneline -n 3 def5678快速比对；注意：git fsck不会列出被 reflog 引用的对象，所以它空≠数据没了 - 最容易被忽略的一点：检查
.git/logs/refs/heads/目录下有没有残留的旧分支日志文件，哪怕分支名大小写不符（如feature/Loginvsfeature/login），文件可能还在，里面存着最后提交哈希
