git pull 与 git fetch 有什么区别
普通 clone 配置下，git fetch 下载远程提交并更新 origin/main 等跟踪引用，不修改工作区；git pull 在 fetch 后按选项和配置执行 merge、rebase 或仅允许快进。想先看远程改了什么再决定，就先用 fetch。
一句话：git fetch 只下载不合并，git pull 会在 fetch 后按选项和配置执行 merge、rebase 或仅允许快进。 在普通 clone 的默认 fetch refspec 下，fetch 不修改当前工作区，只是本地的 origin/main 引用更新了；pull 则会把远程新提交直接合并进你当前分支（或按配置 rebase）。
对比
以下按普通 clone 的默认 fetch refspec 说明。
| git fetch | git pull | |
|---|---|---|
| 下载远程提交 | ✅ | ✅ |
| 更新 origin/main 引用 | ✅ | ✅ |
| 改动当前分支/工作区 | ❌ | ✅（merge 或 rebase） |
| 可能产生冲突 | ❌ | ✅ |
| 安全性 | 随时可跑 | 工作区脏时需谨慎 |
先 fetch 看清楚的套路
git fetch origin
git log HEAD..origin/main --oneline # 远程多了哪些提交
git diff HEAD origin/main --stat # 改了哪些文件
git merge origin/main # 看完再决定合不合
pull 的合并方式
git pull # 行为取决于 Git 版本、配置及分支状态；建议显式指定策略
git pull --rebase # 变基：把你的提交挪到远程提交之后，历史更线性
git pull --ff-only # 只允许快进，有分歧就报错（团队协作推荐）
全局设置：git config --global pull.rebase true 或 pull.ff only。
常见问题（FAQ）
Q：为什么有人推荐永远用 fetch+merge 分两步？
可控：先看清楚远程改了什么、冲突面多大，再决定合并策略。pull 一步到位，冲突来了会被动进入合并状态。新手养成 fetch 先行的习惯更稳。
Q：pull 时工作区有未提交改动会怎样？
如果合并要动的文件你有未提交改动，Git 会拒绝并提示先提交或 stash。merge 对不受影响的本地改动可能允许继续；rebase 通常要求干净工作区，启用 autostash 后恢复本地改动仍可能冲突。
Q：fetch 会让本地分支前进吗？
普通 clone 的默认 refspec 只更新远程跟踪引用；自定义 refspec 可以把 fetch 目标指定为本地分支，因此不能概括为永不更新本地分支。
