Git push报错因默认只推同名远程分支，本地重命名后未设上游导致引用映射缺失；应先用git branch -u origin/old-name new-name绑定追踪，再删旧推新。
远程分支名和本地分支名不一致时，git push 为什么会报错？
因为 Git 默认只推送「本地分支名」到同名的远程分支。如果本地分支已重命名（比如从 feat/login 改成 feat/auth-login），但远程仍保留旧名，直接 git push 会提示 error: src refspec feat/login does not match any——Git 找不到对应源分支。
本质是远程追踪分支（origin/feat/login）还存在，而本地新分支没有设置上游。不是权限或网络问题，纯属引用映射缺失。
- 别用
git push --set-upstream origin feat/login硬推旧名，那只是绕过问题，没解决同步 - 不要手动删远程旧分支再推新分支，容易漏掉 PR 关联、CI 配置等隐性依赖
- 真正要做的，是让本地新分支「接管」原远程分支的追踪关系
git branch -u 怎么安全绑定新本地分支到旧远程分支？
核心命令是 git branch -u origin/feat/login feat/auth-login，它把本地 feat/auth-login 的 upstream 指向远程 origin/feat/login。之后 git push 就会自动推送到那个远程分支，而不是创建同名新分支。
但注意：这个操作本身不改远程分支名，只是建立映射。如果目标是「远程也改名」，必须配合 git push origin :feat/login feat/auth-login（冒号开头表示删除旧分支）。
- 先执行
git branch -u origin/feat/login feat/auth-login，确保本地能正确追踪 - 再执行
git push origin :feat/login feat/auth-login，原子性完成「删旧 + 推新」 - 如果远程有保护规则（如 branch protection），
:删除操作会被拒绝，需先临时关闭或走 UI 操作
写自动化脚本时，哪些变量必须动态提取，不能硬编码？
脚本里最易出错的是把分支名写死。实际应从 Git 状态中实时读取：git symbolic-ref --short HEAD 获取当前分支名，git config branch.$(git symbolic-ref --short HEAD).merge 提取原 upstream 路径，再用 sed 解析出远程分支名。
例如当前在 feat/auth-login，但它的 upstream 还是 refs/heads/feat/login，说明这是个刚重命名的分支——这时才触发同步逻辑。
- 用
git rev-parse --abbrev-ref @{u}更可靠，直接拿到完整 upstream 名（如origin/feat/login） - 远程名（
origin）应通过git config branch.$(branch).remote获取，避免写死 - 脚本开头加
git diff --quiet && git diff --cached --quiet判断是否有未提交改动，有则退出，防止误操作
CI/CD 流水线里执行分支重命名同步，为什么常失败？
CI 环境通常用 git clone --depth=1，导致本地没有完整的 refs/remotes 记录，git branch -u 会报 upstream branch 'origin/xxx' not found。这不是脚本问题，是克隆深度不足。
解决方案只有两个：要么在 CI 中改用完整克隆（--depth=0 或去掉 depth 参数），要么在脚本里主动 fetch 全量远程分支：git fetch origin '+refs/heads/*:refs/remotes/origin/*'。
- GitHub Actions 中，
actions/checkout@v4默认 depth=1，需显式设fetch-depth: 0 - GitLab CI 里，
GIT_DEPTH: 0环境变量即可 - 别依赖
git ls-remote查远程分支——它只返回哈希，不提供本地 tracking 信息
分支名变更看似简单，但 remote tracking ref、local upstream 设置、CI 克隆策略这三者稍有错位，就会导致推送静默失败或关联断裂。关键不是“怎么推”，而是“推之前，Git 是否真知道该推到哪儿”。
