Git重命名分支必须执行“删旧+推新+设上游”三步：先用git branch -m改本地名，再git push origin --delete删远程旧分支，最后git push origin -u新名同步并设置追踪，否则远程残留旧分支导致CI/CD和PR错乱。
Git 没有直接重命名远程分支的命令，必须通过“删旧 + 推新 + 同步追踪”三步完成，否则远程会残留旧分支，CI/CD 和 PR 可能继续指向它。
git branch -m 只改本地，不碰远程
执行 git branch -m old-name new-name 仅修改本地分支引用，HEAD、提交历史、未推送的 commit 全部保留。远程仓库完全无感知——origin/old-name 依然存在，且你的本地分支也不会自动关联到 origin/new-name。
常见错误现象：
- 运行
git branch -m后立刻git push origin new-name，结果远程同时存在old-name和new-name -
git status仍提示 “Your branch is based on 'origin/old-name'”，pull/push 行为错乱
正确做法（当前不在待重命名分支时）：
- 先确认目标分支无未推送提交：
git log origin/old-name..old-name应为空 - 执行
git branch -m old-name new-name - 切回该分支：
git checkout new-name（或git switch new-name）
git push origin --delete 是删除远程分支的唯一安全方式
用 git push origin --delete old-name（Git 2.0+ 推荐）或等价的 git push origin :old-name 删除远程分支。这是原子操作，不会影响其他分支。
容易踩的坑：
- 误写成
git push origin :new-name——这会把刚推上去的新分支又删掉 - 在团队协作中未提前通知：协作者 fetch 后仍保留
origin/old-name追踪，需手动清理 - CI/CD 配置里硬编码了
old-name，删完后流水线直接失败
执行前建议：
- 检查 CI 配置文件（如
.github/workflows/*.yml、.gitlab-ci.yml）是否含old-name - 确认 PR 是否已关闭或合并，避免遗留指向
old-name的链接
git push origin -u new-name 必须在删旧之后执行
删掉远程 old-name 后，再运行 git push origin -u new-name。其中 -u（即 --set-upstream）会把本地 new-name 关联到 origin/new-name，让后续 git pull、git push 默认走这个路径。
注意参数差异：
-
git push origin new-name：只推送，不设置上游 →git status仍显示“no upstream” -
git push origin -u new-name：推送 + 设置上游 →git pull等价于git pull origin new-name -
git push --force origin new-name：完全不需要 force ——这是新增分支，不是覆盖已有内容
若之前已错误推送过 new-name，但尚未删 old-name，此时应先删 old-name，再 git push --force origin new-name 清理冗余，但这种情况极少见。
协作者同步时最容易忽略 git fetch --prune
其他成员执行 git fetch origin 后，origin/old-name 仍会留在本地远程跟踪分支列表里，因为 Git 默认不自动清理已被删除的远程分支引用。
必须主动运行：
-
git fetch --prune origin（推荐）：获取更新并自动删掉本地已不存在的origin/xxx - 或分步：
git fetch origin+git branch -r -d origin/old-name
之后，若他们本地还有 old-name 分支，需手动切换并重设追踪：git checkout old-name && git branch --set-upstream-to=origin/new-name，但更稳妥的做法是直接删掉本地 old-name 分支（前提是无独有提交）。
真正麻烦的点不在命令本身，而在于远程分支名被多处隐式依赖：Webhook URL、部署脚本里的分支判断、代码审查工具的配置项……这些不会随 git push --delete 自动更新。
