git fetch 后看不到新远程分支，是因为本地远程跟踪分支索引未更新；必须执行 git fetch origin（或 git remote update origin）才能将远程分支信息同步至 remotes/origin/* 命名空间，再通过 git branch -a 查看。
直接同步远程分支代码，最稳妥的方式是先 git fetch 拉取元数据，再用 git merge 或 git rebase 显式合并——跳过这一步直接 git pull 容易掩盖问题，尤其在多人协作中。
git fetch origin 后看不到新远程分支？
这是本地分支索引未更新的典型表现。Git 不会自动同步远程分支列表，git branch -a 显示的是缓存快照，不是实时状态。
- 必须先运行
git fetch origin（或简写git fetch），才能把远程所有分支信息下载到本地remotes/origin/xxx命名空间下 - 执行后再次运行
git branch -a，就能看到类似remotes/origin/feature/payment的条目 - 如果只想拉某个分支，用
git fetch origin feature/payment更轻量 - VSCode “发布到 GitHub” 报 “no upstream configured”，往往就是没
fetch过，它默认找origin/main，但远程可能是master或其他名称
git pull origin dev 和 git merge origin/dev 有什么区别？
git pull origin dev 是 git fetch origin dev + git merge origin/dev 的组合，但隐藏了中间状态；而手动分步执行能看清每一步发生了什么。
-
git pull origin dev会强制尝试合并，如果当前分支已存在未提交修改，可能直接失败或触发意外合并 -
git fetch origin dev只下载，不碰工作区和暂存区，安全可控；之后再git merge origin/dev，你可以提前检查git log origin/dev..HEAD看有没有遗漏提交 - 若远程分支名和本地不一致（比如远程叫
release/v2.1，本地叫release-2.1），git pull无法直接指定映射，必须用git fetch+git merge origin/release/v2.1
merge 还是 rebase？关键看提交历史是否要共享
如果你的分支还没推送到远程、也没人基于它开发，git rebase origin/main 能保持线性历史；一旦分支已公开，就该用 git merge。
-
git rebase会重写提交哈希，导致协作中断：别人基于旧 commit 继续开发后，git pull会拉出重复提交，甚至引发二次冲突 -
git merge生成一个合并提交，明确标记集成点，适合主干（如main、develop）或已推送的功能分支 - IDEA 或 VSCode 的图形化 merge 提示，底层仍是调用
git merge，但会自动帮你暂存/恢复未提交修改，比命令行容错高一点
真正容易被忽略的点是：同步前不检查当前分支状态。git status 显示有未提交修改时，git pull 可能拒绝操作，而 git fetch 不受影响——所以日常更新，先 git fetch，再根据 git status 和 git log --oneline origin/main..main 判断要不要 merge 或 rebase，才是稳住节奏的关键。
