git branch -m 仅重命名本地分支，需三步同步远程：先删旧分支 git push origin --delete old-name，再推新分支 git push -u origin new-name，最后协作者执行 git fetch -p 清理远程跟踪引用。
git branch -m 只改本地，远程完全没反应
执行 git branch -m old-name new-name 后，远程仓库里 origin/old-name 依然存在，且你的本地分支不会自动关联到 origin/new-name。此时 git status 很可能提示 “Your branch is based on 'origin/old-name', but the upstream is gone”，git push 还是往旧分支推，git pull 也拉不到新分支内容。
常见错误现象：
- 误以为重命名后直接
git push origin new-name就完事了，结果远程同时存在old-name和new-name - CI/CD 流水线仍触发
old-name的构建任务（因配置文件硬编码） - GitHub/GitLab 上 PR 仍显示为 “Merging into origin/old-name”
关键点：Git 没有原子化的远程重命名操作，必须靠“删旧 + 推新 + 设上游”三步闭环，缺一不可。
删远程旧分支必须用 git push origin --delete
这是唯一安全、可读、兼容性好的方式。别用 git push origin :old-name —— 虽然等价，但部分 CI 工具（如某些 GitLab Runner 版本）会把冒号前空格解析异常，导致误删主干分支。
执行前建议确认远程旧分支确实存在：
-
git ls-remote --heads origin old-name有输出才需删 - 团队协作中，务必提前通知所有人，避免有人正在
old-name上提交未推送的代码 - 检查 CI 配置文件（如
.github/workflows/*.yml、.gitlab-ci.yml）是否含old-name字符串，否则删完立刻失败
推新分支时 -u 必须在删旧之后执行
顺序错了就白干：git push origin -u new-name 必须在 git push origin --delete old-name 之后运行。如果先推新再删旧，中间窗口期远程两个分支并存，PR、权限策略、自动化测试都可能错乱。
-u（即 --set-upstream）的作用是写入配置项 branch.new-name.merge 和 branch.new-name.remote，让后续 git pull、git push 默认走 origin/new-name。它不创建远程分支——只有 git push origin new-name 才创建；-u 只是绑定追踪关系。
如果你本地已存在 new-name 分支但尚未设置上游，可用：
git branch --set-upstream-to=origin/new-name new-name- 或更直接：
git push --set-upstream origin new-name（等价于git push -u origin new-name）
协作者同步不是自动的，git fetch -p 是清理关键
其他人执行 git pull 不会感知分支重命名。他们必须手动更新本地远程跟踪引用：
-
git fetch --prune（简写git fetch -p）会删除本地缓存中已不存在的origin/old-name - 若本地还有同名的旧本地分支（如
old-name），需人工决定是否git branch -d old-name或保留 - 若想把本地
old-name分支切换成跟踪origin/new-name，得先git branch --unset-upstream old-name，再git branch --set-upstream-to=origin/new-name old-name（注意：这时本地分支名没变，只是换了上游）
最容易被忽略的是 IDE 缓存——比如 VS Code 或 IntelliJ 里的分支下拉列表可能仍显示 old-name，需要重启 Git 插件或整个 IDE 才刷新。别只信界面，以 git branch -vv 输出为准。
