应使用git branch --set-upstream-to=origin/feature/login feature/login（显式指定）或git checkout feature/login && git branch --set-upstream-to=origin/feature/login（默认当前分支）设置跟踪；若远程分支不存在，须先git push -u origin feature/login创建并关联。
本地分支没设上游，git push 和 git pull 就只能靠猜——不是报错，就是推错地方。
怎么让已有本地分支跟踪远程分支
你已经切到 feature/login，也确认远程存在 origin/feature/login，但 git branch -vv 显示没有 [origin/feature/login] ——说明没跟踪。这时候不能用 git branch --set-upstream（已弃用），必须用完整写法：
-
git branch --set-upstream-to=origin/feature/login feature/login（显式指定本地分支名） - 或者先
git checkout feature/login，再运行git branch --set-upstream-to=origin/feature/login（省略本地分支名，默认当前分支） - 如果报
error: the requested upstream branch 'origin/xxx' does not exist，不是命令错了，是远程分支根本没被推上去，得先git push -u origin feature/login
创建分支时就绑定远程跟踪关系
别等建完再补，一步到位更稳。两种写法效果一样，推荐后者（语义更清晰）：
-
git checkout -b feature/login origin/feature/login：从远程分支检出并创建本地分支，自动设跟踪 -
git switch -c feature/login --track origin/feature/login：Git 2.23+ 推荐，switch比checkout更专注分支操作 - 注意：
origin/feature/login必须存在（即别人已推或你刚推过），否则会创建一个“分离 HEAD”状态的本地分支，后续还得手动重设
为什么 git push 不带参数会失败
根本原因不是权限或网络，而是 Git 不知道该推到哪。这取决于两个独立配置：
-
push.default：决定“没指定目标时怎么推”。默认是simple，要求本地分支名和远程分支名一致，且已设上游；若设成matching，可能误推一堆分支，尤其在多远程仓库时危险 - 上游分支是否设置：用
git branch -vv看，有[origin/xxx]才算设好；显示[gone]表示远程分支已被删，需git branch --unset-upstream清理后再重设 - 远程名不一定是
origin：比如你加了upstream远程，却对origin设了上游，git push仍往origin推——查所有远程用git remote，设上游时必须写全名，如git branch --set-upstream-to=upstream/main main
远程分支状态不准？别信 git branch -r
git branch -r 列的是本地缓存的远程追踪分支（.git/refs/remotes/origin/ 下的文件），不是远程实时状态。常见误判场景：
- 别人刚推了
feature/v2，你git branch -r看不到 → 先git fetch origin同步引用 -
git branch -a还显示remotes/origin/deleted-branch→ 用git fetch --prune origin清理，或配git config --global fetch.prune true让每次 fetch 都自动 prune - 想确认远程是否存在某分支，又不想拉代码 → 用
git ls-remote --heads origin | grep feature/v2，它直连远程仓库，返回真实 refs
上游跟踪关系不是一次设置就永久有效的事。远程分支重命名、删除、换远程名，都会让本地跟踪失效。最轻量的验证方式，就是每次协作前敲一行 git branch -vv——比翻文档快，也比猜可靠。
