git fetch 不修改工作区，只更新远程跟踪分支（如origin/main），下载远程最新提交但不动当前分支head、暂存区和文件；其核心是安全获取状态供手动审查与合并。
git fetch 不改工作区，只更新远程跟踪分支
执行 git fetch 后，你的文件没变、当前分支 HEAD 没动、暂存区和工作目录完全干净。它只做一件事：把远程仓库最新提交记录下载下来，写入本地的 origin/main、origin/develop 这类远程跟踪分支里。
常见错误现象：git fetch 执行完发现代码没更新，以为命令失败——其实它本就不该更新你正在写的代码。
- 想看远程改了什么？用
git log origin/main..main（对比远程和本地差异） - 想确认是否要合并？先
git diff origin/main main看改动范围 - 想安全合并？等确认无误后手动
git merge origin/main
git pull 是 fetch + merge，一步触发合并逻辑
git pull 本质是两个动作打包执行：先 git fetch 下载，再默认调用 git merge 尝试合入当前分支。这意味着它会直接修改你的工作区文件，可能立即弹出冲突提示。
使用场景有限但明确：你确定本地没未提交改动，且远程更新与你无关（比如 CI 自动推送的文档变更），或者你正处在快速迭代调试阶段，愿意承担即时冲突风险。
- 默认行为是
merge，但可配置为rebase：git config --global pull.rebase true - 显式指定分支更安全：
git pull origin main，避免因 upstream 设置混乱导致意外合并 - 如果本地有未提交修改，
git pull可能失败并提示“本地修改会被覆盖”，这时必须先git stash或提交
FETCH_HEAD 是 pull 的中间状态，也是 fetch 的隐式记录
每次 git fetch 都会把拉下来的最新 commit 写进 .git/FETCH_HEAD 文件。而 git pull 实际上就是读这个文件，再决定 merge 哪个 commit —— 它不是直接 merge 远程分支，而是 merge FETCH_HEAD 指向的内容。
容易踩的坑：
- 执行
git fetch origin feature/x后，FETCH_HEAD记录的是feature/x的 tip，但origin/feature/x远程跟踪分支未必被更新（除非你用了git fetch origin全量拉取） - 手动
git merge FETCH_HEAD是可行的，但不如git merge origin/feature/x清晰可追溯 - 多人协作时，
FETCH_HEAD是临时快照，不保证长期一致；远程跟踪分支才是稳定参考点
什么时候必须用 fetch，而不是 pull
当你不能接受“自动合并”这个副作用时，git fetch 就是唯一选择。这不是保守，而是对当前工作流的尊重。
典型场景：
- 你在本地分支上写了半截功能，还没 commit，但想看看别人刚推的
hotfix是否影响你正在改的模块 - CI 流水线报告某次 push 失败，你想先
git fetch origin拿到最新状态，再比对git log --oneline origin/main ^HEAD确认遗漏了哪些提交 - 团队约定 PR 合并前需人工验证，
git fetch+git checkout -b review/xxx origin/xxx可隔离测试，不污染主开发分支
真正复杂的地方不在命令本身，而在你是否清楚自己此刻需要的是“看见变化”还是“接受变化”。fetch 给你看见的权利，pull 直接替你做了决定。
