Git远程分支清理：解决仓库迁移后的幽灵分支问题

1. 问题场景还原：当远程仓库切换引发连锁反应

上周三凌晨1点，我在重构一个遗留项目的CI/CD流程时，突然遇到一个诡异现象：本地明明存在release分支，Jenkins却持续报错"远程分支不存在"。查看git remote -v后发现，原来项目已从GitLab迁移到GitHub，但本地仓库仍指向旧地址。更麻烦的是，虽然用git remote set-url更新了仓库地址，之前同步过的远程分支引用却像"幽灵"一样残留在本地。

这种情况在团队协作中其实相当常见：

• 代码仓库平台迁移（GitLab→GitHub/Gitee）
• 组织架构调整导致仓库路径变更
• 开源项目fork后需要切换upstream源
• 企业级Git服务域名更新

2. 核心原理拆解：Git的远程跟踪分支机制

2.1 远程引用（remote references）的存储方式

Git在本地维护的远程分支信息，实际上存储在.git/refs/remotes/[remote-name]目录下。例如：

code复制.git
└── refs
    └── remotes
        └── origin
            ├── main
            ├── dev
            └── release

这些文件本质上是文本文件，记录着对应远程分支的commit hash值。

2.2 引用更新的触发条件

当执行以下操作时，Git会自动更新远程引用：

• git fetch
• git pull（隐含fetch操作）
• git remote update

但关键问题是：这些操作只会增量更新，不会删除已经不存在的远程分支引用。这就是为什么切换仓库地址后，旧的远程分支引用会像"僵尸"一样残留。

3. 解决方案深度剖析：git remote prune的运作机制

3.1 命令语法与参数

bash复制git remote prune [-n | --dry-run] [--verbose | -v] <remote>

• -n/--dry-run：模拟执行，显示将被修剪的分支但不实际删除
• -v/--verbose：显示详细操作日志

3.2 底层执行流程

1. 连接远程仓