git fetch只下载远程更新到远程跟踪分支，不修改工作区和当前分支；git pull则是fetch加自动合并，可能引发冲突或覆盖本地更改。
直接说结论：想安全同步，先用 git fetch 看清楚改了啥，再决定要不要合并；图省事且确认无冲突，才用 git pull。用错一个，轻则本地代码被覆盖，重则引入未测试的配置变更或合并冲突。
为什么 git fetch 不会动你当前代码
git fetch 只做一件事：把远程分支的最新 commit-id 和对应对象（树、blob、提交记录）下载到本地，存进 .git/refs/remotes/origin/main 这类远程跟踪分支里。它不碰你的工作区，也不改你当前分支的 HEAD 指针。
- 执行后
git status一定显示 “Your branch is up to date”，因为本地分支没变 - 想看到远程改了啥？用
git log origin/main ^main或git diff main origin/main - 远程分支名可能和本地不同，比如
git fetch origin dev:local-dev会把远程dev拉到本地新建的local-dev分支 - 如果只 fetch 某个分支，
origin/other-branch不会更新 —— 默认只更新你指定的那个
为什么 git pull 容易出问题
git pull 本质是 git fetch + git merge（默认）或 git rebase（加 --rebase 参数）。它跳过了“检查”这一步，直接把远程改动塞进你当前分支。
- 若你本地有未提交修改，
git pull会先尝试自动暂存（git stash），但 stash 失败时直接中止，报错error: Your local changes to the following files would be overwritten by merge - 若远程和本地都改了同一文件同一行，会进入冲突状态，
git status显示 unmerged paths，必须手动编辑、git add、git commit - 默认 merge 会产生一个“merge commit”，污染线性历史；而
git pull --rebase虽能避免，但会重写本地提交哈希，协作中已推送的提交不能再push --force -
git pull origin main和当前分支不是main时，行为取决于分支 upstream 设置，容易误合到错分支
什么时候必须用 git fetch 而不是 git pull
不是“推荐”，而是“非用不可”的场景：
- CI/CD 流水线脚本里拉取代码：不能容忍交互式冲突，必须显式控制合并时机
- 本地有重要未提交调试代码，又想看远程有没有修复某个 bug：
git fetch后git diff origin/main -- path/to/file.c直接比关键文件 - 团队约定用
rebase整理提交历史：先git fetch，再git rebase origin/main，而不是git pull --rebase（后者在某些 Git 版本中会跳过 fetch 步骤） - 远程分支名和本地不一致，比如你想把
origin/release/v2.3合并进本地stable分支：只能git fetch origin release/v2.3，再git merge FETCH_HEAD
FETCH_HEAD 是什么，为什么它常被忽略
FETCH_HEAD 是一个临时指针文件，位于 .git/FETCH_HEAD，每次 git fetch 后都会被重写，记录本次 fetch 获取的远程分支 tip 的 commit-id 和分支名。它是 git pull 能自动合并的关键中介，也是你手动合并时最轻量的引用方式。
-
git merge FETCH_HEAD等价于合并本次 fetch 拿到的最新提交，不用记分支全名 - 但
FETCH_HEAD不持久 —— 下次git fetch就会被覆盖，不能当长期引用用 - 如果 fetch 多个分支（如
git fetch origin main dev），FETCH_HEAD只保留最后一个分支的信息 - 误删
.git/FETCH_HEAD不影响仓库，但会导致git pull报错fatal: Couldn't find remote ref HEAD（需重新 fetch）
