重命名远程分支需三步：删旧分支、推新分支、重建跟踪关系。git branch -m 仅改本地，远程需 git push origin --delete old-name 和 git push origin new-name，再用 git push -u origin new-name 设置上游。
Git 没有重命名远程分支的命令，所谓“重命名远程分支”本质是删旧 + 推新 + 修复跟踪关系三步操作，漏掉任何一步都会导致远程状态混乱、CI/CD 误触发、协作者拉不到正确分支。
git branch -m 只改本地，不碰远程
执行 git branch -m old-name new-name 后，你只是在本地 .git/refs/heads/ 下把引用文件名改了，远程仓库完全无感知。此时运行 git status，大概率看到提示：Your branch is based on 'origin/old-name', but the upstream is gone. —— 这说明上游跟踪已断开，git pull 和 git push 默认仍会去找 origin/old-name。
- 当前就在待重命名分支上时，直接用
git branch -m new-name（单参数），最安全 - 不在该分支上时，必须写全两个参数：
git branch -m old-name new-name；输错旧名，Git 不报错，而是新建一个叫new-name的分支，原分支毫发无损 - 新名含点号、波浪线等特殊字符，必须加引号：
git branch -m "hotfix.1.2" "fix/1.2" - Windows 下大小写不敏感，
main→Main可能静默失败，需加--force（但先确认无同名分支）
远程必须手动删旧分支再推新分支
远程仓库不支持“重命名”，只支持“删除引用”和“创建新引用”。如果只推新不删旧，origin/old-name 和 origin/new-name 会同时存在，后果包括：PR 关联错乱、CI 触发双跑、权限策略失效、团队成员困惑。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 先确认远程旧分支是否存在：
git ls-remote --heads origin old-name（有输出才需删） - 删远程旧分支，推荐写法：
git push origin --delete old-name（可读性强，CI 工具兼容性好） - 推新分支：
git push origin new-name（此时远程只有new-name，但尚未建立跟踪） - 别用
git push origin :old-name new-name—— shell 解析易出错，且无法区分“删旧”和“推新”的成败
上游跟踪关系必须显式重建
git branch -m 不会更新 .git/config 中的 branch.<name>.merge</name> 和 branch.<name>.remote</name> 配置项。残留的旧配置会让所有基于配置的命令（如 git pull、git push 无参数调用）继续指向已删除的 origin/old-name。
- 清除旧上游：
git branch --unset-upstream - 绑定新上游：
git branch --set-upstream-to=origin/new-name new-name - 或者一步到位：
git push -u origin new-name（前提是远程已有new-name；若没有，得先git push origin new-name再设 upstream） - 检查是否生效：
git config --get branch.new-name.merge应返回refs/heads/new-name
协作者同步最容易被忽略
其他成员不会通过 git pull 自动得知分支重命名——Git 不广播这类元信息。他们必须主动清理本地残留的远程跟踪引用，并重新绑定。
- 所有人先执行：
git fetch origin（获取远程分支变更，包括删除） - 查看是否还残留旧远程分支：
git branch -r | grep old-name - 若有，手动删除本地远程跟踪引用：
git branch -r -d origin/old-name - 再切换到对应本地分支，运行：
git branch --set-upstream-to=origin/new-name - 提醒团队：重命名前确保旧分支无未推送提交，否则这些提交将从远程“消失”
真正麻烦的不是命令本身，而是远程分支名一旦被 CI/CD、PR 模板、部署脚本硬编码，改名后这些外部依赖就全得跟着手动更新——这才是多数人重命名失败的根源。
