答案是重命名后需手动清理远程旧分支、推送新分支并设上游、验证追踪关系。git branch -m仅改本地名，不更新远程配置，导致git push -u报“no upstream configured”；必须先git push origin --delete old-name，再git push -u origin new-name，最后git branch -vv确认[new-name]标记。
重命名 Git 分支后 push 失败，不是命令写错了，而是本地和远程的追踪关系断了，且远程旧分支还挂着——必须手动清理、重建、验证三步到位。
git branch -m 后 git push -u 报错 “no upstream configured”
这是最典型的“断联”现象：git branch -m 只改本地分支名，完全不碰远程配置。执行后，新分支在 git branch -vv 中显示没有 [origin/old-name] 这类上游标记，git push -u origin new-name 会因找不到对应远程分支而失败（尤其当远程还没删旧名时）。
- 先确认当前分支是否真没上游：
git branch -vv | grep new-name，如果中括号为空，说明确实没关联 - 别急着推，先查远程现状：
git ls-remote --heads origin | grep old-name，确认origin/old-name是否还存在 - 如果远程旧分支还在，
git push -u origin new-name会失败或意外创建同名新分支（取决于push.default配置） - 正确顺序是：删远程旧分支 → 推本地新名并设上游 → 再验证
git push origin --delete old-name 执行后仍推不上 new-name
删完旧分支不代表新分支就能顺利推上去。常见卡点有三个：
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 远程已有同名分支（别人抢先建了
new-name），此时git push origin -u new-name会拒绝，需协调或换名 - CI/CD 配置（如
.github/workflows/ci.yml）里硬编码了old-name，删完后流水线直接挂掉，得同步更新 - 本地
git config push.default是current或matching，可能误推其他分支；建议全局设为simple：git config --global push.default simple
IDE（VS Code / IntelliJ）里分支名还是旧的、推送目标错乱
IDE 不会自动感知 .git/refs/heads/ 下的引用变更，缓存的是分支名字符串而非实时引用。你看到的“当前分支”可能是上一次打开项目时读取的快照。
- 关掉项目再重开是最稳妥的刷新方式
- VS Code 可手动触发命令面板（Ctrl+Shift+P）→ 输入 “Git: Refresh”
- IntelliJ 系列需右键 Git 工具窗口 → “Remote Branches” → 右键 “origin” → “Fetch”
- 即使 IDE 显示正常，也别信它——最终以
git status和git branch -vv输出为准
协作者 fetch 后仍能 push 到 origin/old-name
这是最容易被忽略的协同风险：git fetch 不会自动删除已不存在的远程跟踪分支，origin/old-name 会一直留在本地 git branch -r 列表里，导致协作者误推、PR 提错目标、甚至覆盖错误分支。
- 每个协作者都需手动清理：
git remote prune origin（推荐）或git branch -r -d origin/old-name - 如果
prune报 “not a valid ref”，说明本地还没 fetch 到远端已删的状态，先git fetch origin再 prune - 团队应同步更新 CI 配置、PR 模板、文档中的分支名，否则问题会反复出现
真正麻烦的从来不是重命名本身，而是“删远程旧引用”和“清本地远端缓存”这两步没人主动做——它们不会报错，但会让协作链路在静默中持续错位。
