在团队协作中，远程分支被合并后删除是常见操作，但本地仓库不会自动感知这个变化，分支列表里往往还会保留那些已经不存在于远端的分支。下面是一次清理这类残留分支的过程记录，包含我如何确认、如何操作，以及操作后如何验证。

先确认现象

我会先运行 git branch -vv 来查看本地分支的追踪状态。这一步是为了确认哪些分支确实已经失去上游引用，而不是凭印象去删。

要判断哪些本地分支对应的远程分支已经不存在，可以先运行 git remote show origin 或 git branch -vv。git branch -vv 会在每条分支的追踪信息中显示远程分支的名称，如果远程分支已被删除，该行通常会显示类似 [origin/xxx: gone] 的状态。注意，这里说的“gone”是本地仓库仍然记录着旧的追踪引用，只有执行清理操作后才会被移除。如果输出中没有标明 gone，说明远程分支仍然存在，或本地分支根本没有设置追踪关系。

这个“gone”标记说明本地分支仍然存在，只是远端对应的分支已经没了。我会再对照一遍 git remote show origin，因为单独看 branch -vv 在大仓库里可能漏掉一些新拉取的分支。

如果输出中出现了别的状态，比如远程分支已经重命名，旧引用也会显示 gone，需要先到远程仓库确认新分支名称，再决定是否重建追踪关系。

容易误判的地方

有一个地方经常被搞混，就是 fetch 和 prune 的关系。

很多人误以为执行 git fetch 就会同步删除本地分支，实际上 git fetch 默认只会更新远程追踪分支的引用，并不会自动剪除已经删除的远程分支。只有加上 --prune 参数，或者单独执行 git remote prune origin，才能真正让远程追踪引用与远端保持一致。另一个常见坑是，删除本地分支并不会影响远程追踪引用，反之亦然，两者需要分别处理。此外，如果本地分支设置了 upstream 但远程分支不存在，git branch -vv 会显示 gone，但某些情况下 git status 也可能提示“不再跟踪”，这时同样需要显式 prune 或改设 upstream。

所以我会把 fetch 和 prune 分开理解：fetch 是更新远程追踪引用的内容，prune 才是清理那些已不存在的引用。如果本地分支没有设置 upstream，git status 可能不会显示 gone，这也是一个容易漏掉的位置。

还有一种情况是远程分支被迁移到新的路径，旧的追踪引用同样会显示 gone。这时需要先确认新分支是否已经拉取到本地，再决定是删除旧分支还是重新设置上游。

建议的处理顺序

确认了 gone 状态后，我的处理顺序是先清理远程追踪引用，再检查本地分支。这样做的好处是，即使误操作，也还保留本地分支可以恢复。

最直接的清理命令是 git remote prune origin，它会删除本地仓库中那些对应的远程分支已不存在的追踪引用，但不会改动本地分支本身。如果你希望自动完成这一操作，可以改用 git fetch --prune，它会在拉取远端信息的同时剪除陈旧的引用。注意，prune 是剪掉跟踪关系，而不是删除本地分支。执行后可以用 git branch -vv 再检查，确认 gone 状态消失，只剩下有实际本地分支对应的远程引用。

清理完追踪引用后，本地分支仍然在。这时我需要用 git branch 列出所有本地分支，找出那些刚刚失去上游的分支。我会先用 git log 看一下每个分支上是否有独有提交，如果确认没有需要保留的提交，再删。

如果分支数量多，可以先用下面这行把所有 gone 分支列出来，确认后再手动处理，避免自动命令里因为当前分支的星号导致误删。

git branch -vv | grep ': gone'

然后根据列出的分支名，用 git branch -d 逐个删除。git branch -d 会更安全，因为它会拒绝删除未合并的分支。

如果分支上还有需要保留的提交，可以先创建一个备份标签，例如 git tag backup/my-feature my-feature，然后再删除本地分支。这样即使误删，也能从标签找回。

验证与风险边界

操作完以后，我会再跑一次 git branch -vv，确认 gone 标记已经消失，只剩正常的追踪分支。同时 git branch 确认本地分支列表也是预期的。

删除本地分支时要特别注意 -d 和 -D 的区别。git branch -d 会检查分支是否合并到当前分支或上游分支，如果未合并拒绝删除；但远程删除后，本地分支可能还保留着未推送的提交，这时 -d 也会拒绝。如果确认那些提交不要了，才用 -D 强制删除。强制删除没有回滚途径，所以我会先记录分支顶部的 commit 哈希，至少留个线索。

团队协作时还要先确认其他同事是否仍在依赖这个分支。即使远程已经删了，本地分支可能还有其他人的工作，不能只看状态就删。

如果删除后发现需要恢复，git reflog 通常还能找到分支删除前的提交。你可以从那个 commit 重新创建分支，但这需要 reflog 没有被大量新操作覆盖，所以越早处理越容易恢复。

后续维护

为了避免以后反复出现这类残留，我通常会定期运行 git fetch --prune，或者把 git fetch --prune 写进自己的拉取命令里。也可以在团队约定中要求删除远程分支后，每个人及时执行一次 prune。

另外，也可以先执行 git remote prune origin --dry-run 查看会删掉哪些引用，然后再实际执行。这样能减少意外改动。