git fetch 不修改工作区、暂存区和本地分支，仅更新远程跟踪分支和 FETCH_HEAD；git pull 则自动执行 fetch + merge/rebase，可能覆盖代码或触发冲突。
git fetch 不会改你当前的代码，但 pull 会
这是最直接、最常踩坑的区别。执行 git fetch 后，你的工作目录、暂存区、当前分支（比如 main）完全不变；它只更新远程跟踪分支（如 origin/main）和 .git/FETCH_HEAD 文件。而 git pull 在 fetch 完成后立刻执行 git merge（或 git rebase，取决于配置），可能直接修改你的工作区，触发冲突并中断当前流程。
常见错误现象：
- 刚改了几行代码，
git pull后发现文件被覆盖或报 conflict —— 因为 merge 自动介入了 -
git status显示“Your branch is behind 'origin/main' by 3 commits”，但git fetch后运行git status仍显示“up to date”—— 因为它没动本地分支指针
fetch 支持精细控制拉取范围，pull 默认绑定当前分支
git fetch 的参数灵活得多，适合审查、比对、临时同步等场景；git pull 的默认行为是“拉指定远程分支 → 合并到当前检出分支”，容易忽略隐含依赖。
-
git fetch origin feature/login：只拉feature/login分支元数据，不碰其他分支 -
git fetch origin main:tmp：把远程main拉到本地新建的tmp分支，不干扰main -
git pull origin dev：会尝试把远程dev合并进你当前所在的分支（哪怕你当前在main上）—— 这很危险，Git 通常会拒绝，但配置不当可能静默失败 - 想看远程改了什么？先
git fetch，再git log HEAD..origin/main或git diff HEAD...origin/main
pull 的合并策略不是固定的，但很多人不知道它可配
git pull 默认走 merge，但可通过配置切换为 rebase，这会影响提交历史结构和后续 push 行为。
- 全局设为 rebase：
git config --global pull.rebase true，之后git pull等价于git fetch && git rebase origin/main - 仅对某仓库生效：
git -C /path/to/repo config pull.rebase true - 临时覆盖：
git pull --rebase origin main - 注意：如果本地有未推送的提交，
rebase会重写 commit ID，之后git push需加--force-with-lease，不能直接push
FETCH_HEAD 是 fetch 的关键中间状态，pull 用完就丢
.git/FETCH_HEAD 是 git fetch 写入的临时记录，保存本次获取的远程分支最新 commit ID 和 ref 名称。它是手动合并的依据，也是 git pull 内部调用 git merge 时的默认目标。
-
git fetch origin main后，FETCH_HEAD里会有一行类似：abc1234567890... branch 'main' of https://github.com/xxx/yyy -
git merge FETCH_HEAD就等价于git merge origin/main（前提是 fetch 时没指定 refspec） -
git pull执行完，FETCH_HEAD仍存在，但没人再读它——因为 merge 已完成，目标已固化到本地分支 - 误删
FETCH_HEAD不影响已有分支，但会导致下一次git pull前必须重新 fetch（它会重建）
pull 前，得想清楚：我是否准备好接受自动合并？有没有正在编辑的文件？远程改动是否经过人工 review？这些判断点，fetch 把它们暴露出来，pull 则悄悄藏进一步操作里。 
