根本原因是远程分支未推送或未拉取；需先用git push -u origin branch推送并设上游，或确保git fetch后远程分支已存在于本地追踪引用中。
git branch --set-upstream-to 为什么报错 “upstream branch does not exist”
根本原因不是命令写错了，而是远程分支压根没被推上去或没被拉下来。Git 不会自动帮你把本地分支“发布”到远程，也不会自动同步别人新推的分支。
- 先确认远程是否存在该分支：
git ls-remote --heads origin feature/login—— 如果无输出，说明远程仓库里根本没有这个分支 - 如果远程已有，但本地
git branch -r看不到，说明你没执行过git fetch origin，本地缓存还没更新 -
git branch --set-upstream-to=origin/feature/login feature/login中的origin/feature/login必须是本地已知的远程追踪引用（即 fetch 过的），否则必报错 - 最省事的解法：直接
git push -u origin feature/login，一次完成推送 + 设置 upstream
git branch -vv 显示 [gone] 是什么意思
说明你本地配置了跟踪某个远程分支，但那个远程分支已经被删了——不是 Git 同步慢，是远端真没了。
-
git branch -vv输出中出现dev [origin/dev: gone]，代表origin/dev这个远程追踪引用还留着，但远程仓库上dev分支已不存在 - 这不是警告，是事实陈述；继续
git pull会失败，git push也可能被拒绝（取决于远程策略） - 清理方式只有两个：
git branch --unset-upstream dev（只取消跟踪），或git remote prune origin（批量清理所有已失效的remotes/origin/*） - 注意：
git remote prune origin不会影响本地开发分支（如dev），只删remotes/origin/dev这类只读缓存
git checkout -b feature/x origin/feature/x 和 git switch -c feature/x --track origin/feature/x 有什么区别
核心差异在“是否允许覆盖已有本地分支”和“行为是否显式可控”。
-
git checkout -b feature/x origin/feature/x：如果本地已有feature/x分支（哪怕没跟踪任何远程），它会静默切换过去，不报错也不重置，容易误操作 -
git switch -c feature/x --track origin/feature/x（Git 2.23+）：只要本地分支已存在，就直接报错退出，强制你先决定是删、是重命名、还是换种方式处理 - 两者都要求写全
origin/feature/x—— 漏掉origin/就变成创建空本地分支，后续git pull仍会提示 “not currently on a branch” - 如果你用的是老版本 Git（git checkout -b 是唯一选择，但务必加
-f参数确认覆盖意图：git checkout -f -b feature/x origin/feature/x
为什么 git push 不带参数失败，而 git branch -vv 显示有 [origin/main]
可能上游配置存在，但不符合当前 push.default 策略的要求。
- 运行
git config push.default，如果输出不是simple（比如是matching或upstream），行为会完全不同 -
simple要求：本地分支名 = 远程分支名，且已设 upstream；否则拒绝无参git push - 常见陷阱：本地分支叫
feat/login，但 upstream 设成了origin/main—— 名字不一致，simple模式下直接拒推 - 临时绕过：用
git push origin feat/login显式指定；长期解法是重设 upstream：git branch --set-upstream-to=origin/feat/login feat/login - 别全局改
push.default成current，它会把当前分支名无条件推到远程同名分支，多远程时极易推错仓库
git branch -a 或 VSCode 左侧分支列表能反映远程实时情况——它们全靠本地缓存，而缓存必须由 git fetch 主动刷新。
