git fetch 后工作区文件不变，因为它只下载远程提交并更新远程跟踪分支，不修改工作区或 HEAD；需手动 merge 或 rebase 才能更新本地分支。
git fetch 之后，为什么工作区文件没变
因为 git fetch 只下载远程提交对象并更新远程跟踪分支（比如 refs/remotes/origin/main），它完全不修改你的工作区或当前分支的 HEAD 指针。你执行完 git fetch origin，README.md 还是原来的内容，这是正常行为，不是命令失败。
验证是否真的拉到了新提交：用 git log --oneline --left-right HEAD...origin/main。右边出现提交哈希，说明远程有新东西，只是还没合并进来。
常见错误现象：
- 执行
git pull没反应 → 实际可能是本地分支已和origin/main一致，但远程已有新提交，只是你没fetch过 - 编辑器里看不到同事新加的函数 → 八成是只做了
git fetch，没做后续合并或重基
git pull 等价于 fetch + merge，但默认策略可能出问题
git pull origin main 本质是先 git fetch origin main，再自动执行 git merge origin/main。这个“自动 merge”在多人协作中容易引发非预期的合并提交（merge commit），尤其当你本地有未推送的提交时。
更干净的做法是分两步手动控制：
- 先
git fetch origin拉取所有远程分支的最新状态 - 再根据场景选：
git merge origin/main（保留合并历史）或git rebase origin/main（线性历史，适合功能分支） - 如果当前分支已关联远程（
git branch -vv显示[origin/main]），可直接git pull --rebase避免多余 merge 提交
注意：git pull --rebase 不会改变远程分支结构，但它会重写你本地未推送的提交——如果你已经把某些提交推到远程，再 rebase 就会造成历史不一致，必须避免。
远程分支删了，本地还留着？用 --prune 清理
同事删掉远程的 feature/login 分支后，你执行 git fetch origin，git branch -r 仍能看到 origin/feature/login ——这不是 bug，是 Git 默认不主动清理过期的远程跟踪引用。
解决方法很简单：
- 日常同步时加
--prune参数：git fetch --prune origin - 设为全局默认：
git config --global fetch.prune true，之后所有git fetch都自动 prune - 也可以用
git remote prune origin单独清理，但不如--prune一步到位
不清理的后果：git branch -a 列出大量已失效的远程分支，干扰判断；某些自动化脚本可能误读这些残留引用。
同步时遇到 “non-fast-forward” 拒绝推送，说明本地落后且有分叉
执行 git push origin main 被拒绝，并提示 Updates were rejected because the tip of your current branch is behind —— 这不是权限问题，而是远程分支已经有别人推了新提交，而你的本地 main 还停留在旧位置。
正确应对步骤：
- 先
git fetch origin拿到远程最新状态 - 再
git merge origin/main或git rebase origin/main整合变更 - 解决可能出现的冲突（仅发生在 merge/rebase 过程中）
- 最后
git push origin main才能成功
容易被忽略的关键点：不要试图用 git push --force 强推绕过，这会抹掉他人提交；也不要删仓库重 clone——既丢本地未提交修改，又破坏本地 reflog 历史。
