遇到分支同步问题，我一般先做两件事：看本地工作区干不干净，再记录当前 HEAD 哈希。这两个检查决定了后续操作是安全合并还是先避开冲突。很多同事习惯直接 git pull，等冲突弹出来再处理，这其实把检查动作延后了。
先确认现象：分支指针和工作区状态
先执行 git status，再执行 git rev-parse HEAD。如果工作区有未提交改动，暂时先不要执行 pull。原因在下面这段解释里：
git fetch与git pull在分支管理上最核心的区别在于是否移动当前分支的指针并更新工作区。git fetch只会从远端拉取新的提交对象到本地仓库，远端的引用会更新到FETCH_HEAD或对应的远端跟踪分支，但你的本地分支和文件内容完全不动。git pull则隐式执行了git fetch，然后立即将远端跟踪分支合并到当前分支，所以一旦执行，当前分支的指针就会前进，工作区也随之变化。如果你只想先看看远端有什么改动而不想影响手上正在做的事，fetch是安全的选择。
这里的关键词是“动或不动”。git fetch 只动远端跟踪分支，git pull 会动本地分支指针。所以当你只是想了解远端进度时，fetch 是不改动本地现场的唯一选项。
最容易误判：pull 自带合并，不只是拉取
很多人把 pull 理解成“更新到最新”，忽略了它同时触发了 merge。merge 意味着可能有冲突，需要你处理。这种混淆在团队协作中很常见。
判断该用fetch还是pull，可以看当前分支是否有未提交的改动。如果工作区不干净，git pull可能会因为合并冲突而被拒绝，导致你不得不先处理stash或commit；而git fetch无论工作区多脏都不会报错。另一个判断点是：你是否需要在合并前审查代码差异。如果希望先知道本地和远端差了多少个commit、改了哪些文件，就用git fetch，然后再用git log或git diff去比较。如果确认没问题直接更新，才用git pull。
所以，判断是否用 pull，最简单的标准是：你是否已经准备接受一个合并结果。如果不想，就用 fetch。
建议的处理顺序：先 fetch 再决定
当我需要更新一个长期分支，通常会执行 git fetch origin，然后立刻查看本地与远端的差异：git log --oneline --decorate HEAD..origin/当前分支名，再看 git diff --stat。这个顺序能让你在触发合并之前掌握全部改动面。如果确认差异符合预期，再直接 git pull，或者因为已经 fetch 过了，用 git merge origin/当前分支名 效果等价。
这里有一个实际坑：如果当前分支没有上游跟踪信息，git pull 会直接报错提示缺少跟踪信息，但 git fetch 不需要上游跟踪，指定远端名就能跑。所以拿到新分支时，先 fetch 一定不会被卡住。
风险边界：冲突与历史改写
git pull 的风险集中在合并冲突，git fetch 完全不触发合并，所以风险边界很清楚。
git fetch是纯读取远端数据，不会产生任何合并冲突，也不会改写你本地任何分支，风险完全可控。git pull则等于fetch+merge，合并过程可能产生冲突，尤其是本地分支和远端分支分叉较大时。冲突文件会直接写入工作区，你必须手动解决。更隐蔽的风险是，如果你习惯用git pull --rebase，它会改写你本地尚未推送的提交，虽然能让历史线性，但如果你已经把这些提交推到了别的远端，就会造成历史紊乱。所以共享分支上谨慎使用rebase式pull。
如果 merge 冲突已经发生，先 git status 看 unmerged 文件，然后逐个解决。想放弃合并，可以用 git merge --abort；如果是 rebase 类型，用 git rebase --abort。这两个命令会尝试回到操作前状态，但工作区如果有其他未保存改动，需要先 stash。
验证方法：记录 HEAD 哈希和引用指向
操作前后对比最可靠。
要直观理解fetch和pull对本地引用和工作区的影响，可以在执行前记录当前分支的HEAD哈希，例如git rev-parse HEAD。执行git fetch后再对比，HEAD哈希没有变化，远端跟踪分支的哈希变了；执行git pull后再对比，HEAD哈希向前移动了。另外，可以用git status检查工作区是否干净，用git log --oneline --decorate -3查看引用指向，这样能清晰看到fetch只动origin/xxx而pull动本地分支。这些方法能帮你确认当前分支的真实状态。
在这基础上，我还会额外检查未推送的提交：git log origin/当前分支名..HEAD。如果本地有未推送提交，pull 产生的合并提交可能会让历史变得复杂。对于共享分支，建议先沟通再决定用 merge 还是 rebase。
后续维护：把 fetch 当成默认动作
日常开发中，把 git fetch 当作进入工作前的第一步比较稳妥。它不改变本地分支，能让你看到远端变化，再根据差异决定下一步。这样分支关系保持透明，也避免每次都被 pull 的隐式合并打个措手不及。