git重命名远程分支本质是删旧分支、推新分支、修复追踪三步操作；仅用git branch -m只改本地名，不触碰远程，会导致ci/cd异常、pr错乱及协作者pull失败。
Git 没有直接重命名远程分支的命令，所谓“重命名远程分支”，本质是删旧 + 推新 + 修复追踪三步缺一不可。只跑 git branch -m，远程还留着旧名，CI/CD 继续跑、PR 关联错乱、同事 git pull 报错，都是必然结果。
git branch -m 只改本地，不碰远程
这是最常被误解的一点。git branch -m 完全只操作本地 .git/refs/heads/ 下的引用文件，和远程仓库零交互。
- 当前在待重命名分支上：直接运行
git branch -m new-name - 不在该分支上：必须写全
git branch -m old-name new-name - 如果
new-name已存在，Git 立即报错：fatal: A branch named 'xxx' already exists. - 重命名后立刻
git status，大概率看到提示：Your branch is based on 'origin/old-name', but the upstream is gone.—— 这说明上游配置已失效，但 Git 不会自动清理
远程分支必须手动删旧推新
远程仓库没有“重命名”语义，只有“删除引用”和“创建引用”两个原子操作。不删旧分支，会导致 origin/old-name 和 origin/new-name 并存，后果严重：
- CI/CD 流水线可能仍监听
origin/old-name，构建污染或误触发 - GitHub/GitLab 的 PR base 分支下拉菜单里会出现两个同源分支，新人极易选错
- 分支保护规则（branch protection）若只配了
old-name，new-name就裸奔了
安全做法分两步：
先确认远程旧分支是否存在：git ls-remote --heads origin old-name（有输出才需删）
删远程旧分支：git push origin --delete old-name（别用 git push origin :old-name，部分 CI 工具不兼容）
推新分支并设上游：git push -u origin new-name（-u 会自动设置 branch.new-name.merge 和 branch.new-name.remote）
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
上游跟踪关系不会自动更新
git branch -m 不会动任何 config 配置项，旧的 branch.old-name.merge 和 branch.old-name.remote 依然躺在 .git/config 里。这意味着：
-
git pull默认仍找origin/old-name，报错“upstream not found” -
git push默认也试图推到origin/old-name，失败
正确修复方式有两种：
方案一（推荐）：先清旧再绑新git branch --unset-upstreamgit branch --set-upstream-to=origin/new-name
方案二：一步到位，但前提是远程已有 new-namegit push -u origin new-name
注意：如果远程还没有 new-name，git push -u 会先创建它，再设上游；但如果之前没删旧分支，git push -u 不会帮你删旧的。
团队协作时最容易忽略的三个点
重命名不是单机操作，而是分布式元数据同步。以下三点一旦漏掉，协作立刻出问题：
- 没通知团队：协作者
git fetch后仍保留origin/old-name远程跟踪分支，需要手动git branch -r -d origin/old-name - 没更新 CI/CD 配置：Jenkins pipeline 或 GitHub Actions 的
on.push.branches必须同步改成new-name - 默认分支改名没进 GitLab/GitHub 设置页：如果重命名的是
master→main，必须去Settings → Repository → Default branch手动切换，否则 clone 出来还是老默认分支
真正麻烦的从来不是命令本身，而是那些散落在 Git 配置、CI 配置、权限系统、项目管理工具里的隐式依赖。每次重命名前，先查 git branch -avv，再扫一遍 CI 和分支保护规则，比事后救火快十倍。
