git branch --set-upstream-to= 是设置本地分支跟踪远程分支的最直接、推荐命令，用于明确绑定本地分支与远程分支，使 git pull/git push 无需重复指定远程名和分支名，支持为当前或非当前分支设置，且兼容 Git 1.8.0+。
git branch --set-upstream-to 是最直接的命令
设置远程跟踪分支本质是让本地分支记住它该“跟着”哪个远程分支走，后续 git pull 和 git push 才能免输远程名和分支名。最常用、最明确的方式就是用 git branch --set-upstream-to，它不依赖当前分支状态，也不要求远程分支已存在（只要你在 push 时加上 -u 就会自动建立）。
常见错误是误用已废弃的 git branch --set-upstream（缺少 -to），Git 会报错：error: unknown option `set-upstream`。别被旧教程带偏。
- 为当前分支设置：运行
git branch --set-upstream-to=origin/main - 为其他分支设置（不切换）：加
-b参数，如git branch --set-upstream-to=origin/feat-login login - 如果远程分支还不存在，先
git push -u origin main，-u会一次性完成推送 + 设置跟踪
git push -u origin branchname 的隐式设置逻辑
git push -u 不仅推送代码，还会把本地分支和刚推上去的远程分支“绑定”起来，这是最自然的建跟踪关系时机——尤其适合新功能分支首次发布。
注意：这个操作只在首次推送时有效；之后再用 git push -u 会报错 fatal: The upstream branch of your current branch does not match the name of your current branch，因为 Git 已经记住了上游，不能再强行重绑（除非先用 --set-upstream-to 覆盖）。
使用 gh project CLI 管理 GitHub Projects v2。在代理需要列出待办事项、设置项目字段（如状态、迭代、优先级等）时使用此技能。
- 正确做法：新分支开发完，执行
git push -u origin feat/search - 错误做法：以为多加几次
-u能“刷新”关系，实际会失败 - 如果远程分支名和本地不一致（比如本地叫
dev，想跟踪origin/develop），必须用--set-upstream-to显式指定
检查和验证跟踪关系是否生效
光设了不确认，等于没设。两个最可靠的验证方式：
- 看
git status输出：如果有跟踪关系，会显示类似Your branch is ahead of 'origin/main' by 2 commits. - 查配置项：
git config --get branch.main.merge应返回refs/heads/main，git config --get branch.main.remote应返回origin - 简写命令
git branch -vv：带[origin/main]的那一列就是跟踪目标，星号旁显示ahead/behind表示同步状态
容易忽略的是：如果远程仓库地址变了（比如从 HTTPS 换成 SSH），或远程名被改过（git remote rename origin upstream），原有跟踪关系不会自动更新，必须手动用 --set-upstream-to 重新指定。
不同 Git 版本对 upstream 参数的兼容性
Git 1.8.0+ 全面支持 --set-upstream-to，但如果你在 CI 环境或老旧服务器上遇到 unknown option，大概率是 Git 太老。别升级 Git，换命令就行：
- Git < 1.8.0：用
git config branch.<code>main.remote origin 和git config branch.<code>main.merge refs/heads/main 手动写配置 - Git 2.0+：
--set-upstream-to是唯一推荐方式，git branch -u是它的等效简写（但可读性差，不建议日常用） - 所有版本都认
git push -u，它是跨版本最稳的操作
真正麻烦的不是命令记不住，而是团队里有人用老 Git、有人改过 remote 名、还有人习惯手写 config——这些都会导致 git pull 突然不按预期走远程分支。每次协作前花 10 秒跑一遍 git branch -vv，比事后查 merge 冲突省力得多。
