git fetch 后本地看不到远程新提交，是因为它只更新远程跟踪分支（如 origin/main）而不改变当前本地分支指针；需手动执行 git merge 或 git rebase 整合，或直接使用 git pull。

git fetch 之后为什么本地看不到远程分支的新提交？

因为 git fetch 只下载远程分支的引用和对象，不会自动更新你的本地分支指针。你看到的 origin/main 是更新了，但 main（你当前检出的分支）仍停在旧位置。

常见现象：运行 git fetch origin 后执行 git log，最新提交还是几天前的；但 git log origin/main 却能看到新记录。

• 想让本地分支跟上远程，得用 git merge 或 git rebase 显式整合 origin/main
• 更直接的做法是 git pull origin main —— 它等价于先 fetch 再 merge
• 如果本地有未提交修改，git pull 可能触发合并冲突；此时建议先 git stash，拉完再 git stash pop

git pull --rebase 和 git pull 有什么实质区别？

区别在整合策略：git pull 默认执行 git merge，生成一个合并提交；git pull --rebase 则把本地未推送的提交“重放”到远程分支最新提交之后，保持线性历史。

适用场景：你本地只有自己提交、且希望避免无意义的 merge 提交时，优先用 --rebase。但要注意：

Ainative Git Workflow

Git 提交、PR 与分支规范，对 AI 归属零容忍。适用于创建提交、编写提交信息、创建 Pull Request。

下载

• 如果已把本地提交推送到远程（比如协作分支），再用 --rebase 会改写历史，其他人 pull 会出问题
• git pull --rebase 遇到冲突时，需手动解决后执行 git add + git rebase --continue，不能用 git commit
• 可设为默认行为：git config --global pull.rebase true，但团队应统一约定

如何只同步某个远程分支，不碰其他分支？

默认 git fetch 会拉取所有远程分支的更新。要精准控制，必须显式指定远程名和分支名：

• 仅获取 origin 的 dev 分支：git fetch origin dev
• 这会在本地创建/更新 origin/dev，但不会动 dev 分支本身
• 若想让本地 dev 跟上：git switch dev && git merge origin/dev（或 rebase）
• 注意路径写法：git fetch origin refs/heads/main:refs/remotes/origin/main 是底层等价写法，日常不用

git remote update 和 git fetch origin 有什么不同？

git remote update 会遍历所有已配置的远程仓库（比如 origin、upstream），对每个都执行 fetch；而 git fetch origin 只针对 origin。

容易被忽略的点：

• 如果项目配置了多个远程（如 fork 后同时有 origin 和 upstream），git remote update 可能拉下大量无关更新，拖慢速度
• git remote update 不接受分支名参数，无法限定分支；必须用 git fetch <remote><branch></branch></remote> 才能精准同步
• 某些 CI 环境或脚本里误用 git remote update，结果拉了 upstream 的巨量历史，导致超时

实际操作中，最轻量安全的同步方式就是 git fetch origin main && git merge origin/main —— 每一步意图清晰，出错时也容易定位。别图省事直接 git pull，尤其在多人共用分支时，多敲两个词换来的是历史可读性和协作确定性。