项目交接时必须清理已合并且确认废弃的git远程分支，否则接手人将因认知混乱从错误分支开始工作；需用git branch -r --merged origin/main导出清单并人工核对，删除后执行git fetch --prune同步本地引用，并在文档中明确要求接手方运行git fetch -p。
项目交接时，Git远程分支不清理，接手人极大概率会从一个错误分支开始工作——不是代码问题，是认知混乱。
交接前必须确认的远程分支状态
接手方第一次 git clone 或 git fetch 后看到的 origin/xxx 列表，就是他对项目分支结构的全部初始认知。如果里面混着已合并的 feature/user-auth-2023、命名模糊的 tmp-fix、甚至带日期后缀但早已废弃的 hotfix/v1.4.2-202405，他无法靠名字判断是否该用。
- 移交方应运行
git branch -r --merged origin/main（或origin/master），导出所有已合并的远程分支清单，逐个核对是否真可删 - 特别注意那些带
experiment/、draft/、wip-前缀的分支，它们往往没有 merge commit，但实际已弃用 - 不要依赖“分支名里有 old 就安全删”——我见过
feature/payment-old是当前线上支付回滚通道的唯一备份分支
删除远程分支后，本地残留引用怎么同步
执行 git push origin --delete feature/login 只删了远程服务器上的分支，你本地的 origin/feature/login 追踪引用还在。接手人拉完代码，git branch -a 仍会显示它，点进去却报错 fatal: ambiguous argument 'origin/feature/login': unknown revision。
- 移交方应在删完所有远程分支后，运行
git fetch --prune（或git fetch -p），清掉自己本地的过期origin/xxx - 交接文档里必须写明：“请接手方首次运行
git remote update origin --prune或git fetch -p，否则git branch -r显示不准确” - VS Code 等 IDE 不自动触发 prune，需手动在命令行执行，不能只靠图形界面刷新
哪些分支绝不能删，但容易被误判
看似废弃，实则承担关键职责的分支，在交接时最容易被当成垃圾清理掉。
-
release/v1.5类分支：可能没 merge 回 main，但对应正在灰度的生产环境版本，CI/CD 流水线仍在监听它 -
gh-pages或docs：静态站点托管分支，删除会导致文档服务中断，且无明显代码关联 - 以团队成员名或 Jira ID 命名的分支（如
zhangsan/jira-1234）：可能是未合入的 hotfix，也可能是遗留的权限隔离分支 - 所有
origin/HEAD指向的默认分支（常为origin/main）：删它等于让新克隆仓库无法自动检出主干
交接文档里必须包含的 Git 分支快照
文字描述不如一次 git ls-remote --heads origin 的原始输出可靠。这个命令返回的是远程仓库当前真实存在的所有分支引用，不含任何本地缓存干扰。
- 把该命令输出保存为
remote-branches-on-20260615.txt，和交接包一起交付 - 对比该文件与接手方执行同命令后的结果，能立刻定位是否遗漏 prune 或误删
- 避免使用
git branch -r截图——它依赖本地 fetch 状态，不可复现
真正难的不是删分支，是判断哪条线还连着线上服务、哪条线只是没人记得关的告警通道。交接时多花十分钟确认一个分支的存活证据，比接手后花半天排查“为什么这个分支 checkout 不出来”划算得多。
