必须执行 git remote prune origin 才能同步远程真实状态，因其直接扫描 .git/refs/remotes/origin/ 下文件并与远程逐个校验，而 git fetch --prune 依赖配置且可能失效。
本地分支删了，git branch -r 里还挂着 origin/xxx？这不是 UI 延迟，是 Git 本地引用没真正清理——必须执行 git remote prune origin 才能同步远程真实状态。
为什么 git fetch --prune 有时不生效
它只在 fetch 过程中“顺手”修剪，但前提是你的 fetch 配置能拉到完整远程引用。常见失效点：
-
git remote set-branches origin '*'没配：Git 默认可能只跟踪main和develop，--prune就无从判断其他分支是否已删 - 你用的是
git pull：它不继承fetch.prune配置（哪怕你设了fetch.prune true） - 远程用了 refspec 过滤（比如
+refs/heads/main:refs/remotes/origin/main）：fetch --prune不会碰未被 refspec 覆盖的本地引用
真正可靠的做法是绕过 fetch，直接比对：git remote prune origin。它扫描 .git/refs/remotes/origin/ 下所有文件，和远程真实状态逐个校验，不存在即删。
如何识别并批量删除 [gone] 状态的本地分支
git branch -vv 输出里带 [origin/xxx: gone] 的分支，说明远程已删、本地还留着引用。这类分支不能靠 --merged 判断，得靠文本匹配：
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
- 先确认哪些分支处于
gone状态：git branch -vv | grep ': gone]' - 提取分支名并安全删除（跳过当前分支）：
git branch -vv | grep ': gone]' | awk '{print $1}' | xargs -r git branch -d - 如果想强制删（比如某些分支被误标为
gone但确实无用）：git branch -vv | grep ': gone]' | awk '{print $1}' | xargs -r git branch -D
注意：xargs -r 可避免空输入时报错；awk '{print $1}' 提取的是第一列分支名，不含星号或空格干扰。
清理前先看清楚：哪些大文件在拖慢仓库
分支清理只是表象，真正让 .git 膨胀的是历史里的大文件。别急着重写历史，先定位元凶：
- 查打包文件里最大的 10 个 blob：
git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -10 | cut -d' ' -f1 - 把 hash 转成路径：
git rev-list --objects --all | grep "^<hash>"</hash> - 检查是否已被
.gitignore覆盖：git ls-files | grep -E '\.(zip|pdf|mp4|iso|log)$'
如果发现构建产物或日志被提交过，后续要用 git filter-repo（不是 filter-branch）清理，但那已是另一层操作——分支清理本身不碰对象数据库，别混淆动作边界。
真正容易被忽略的是：清理完远程分支后，git remote prune origin 必须手动触发；VSCode 或其他 GUI 工具不会自动帮你做这步，它们只读本地引用。你看到的“残留”，往往就是这个 gap。
