fetch 与 pull 的区别

很多 Git 同步困惑，根源不是命令难，而是把“先知道远端变了什么”和“立刻把变化整合进当前分支”混成了一件事。

先拿到

远端引用变化分支是否分叉本地未发布提交

→fetch → inspect → choose

再决定

ff-onlymergerebase先不动

同步最贵的错误，往往不是没拉到，而是没看清就改了当前分支。

先记住结论

• git fetch：下载远端最新信息，但不直接改你的当前分支
• git pull：先 fetch，再把远端变化整合进当前分支

这也是为什么很多团队更推荐：

git fetch origin
# 看清楚变化后，再决定 merge 或 rebase

为什么 fetch 更适合作为默认习惯

因为它把两类动作拆开了：

1. 更新你对远端状态的认知
2. 改变当前分支

一旦拆开，你就能先观察：

• 远端是否比本地更新
• 当前分支是否已经分叉
• 接下来更适合 merge、rebase，还是只做 fast-forward

pull 到底可能做出什么

很多人把 pull 理解成“安全同步一下”，但它其实至少包含两段：

• fetch
• 整合

整合阶段可能表现为：

• fast-forward
• merge
• rebase

所以 pull 的风险不在于它“危险”，而在于它把观察和修改捆绑在一起。

一个更稳的判断顺序

面对远端更新时，推荐按下面的顺序想：

1. 我现在只是想知道远端变了没有吗
2. 我已经准备好把这些变化整合进当前分支了吗
3. 这次整合应该是 merge、rebase，还是只允许 ff-only

只要把这 3 个问题分开，很多 Git 同步困惑都会明显减少。

推荐的教学用法

对个人分支

git fetch origin
git rebase origin/main

对稳定主分支

git pull --ff-only

--ff-only 的好处是：如果本地和远端已经分叉，它会直接失败，而不是替你做一个你没意识到的整合动作。

一个典型场景

你早上打开项目，想确认今天开始工作前该怎么同步：

git status
git fetch origin
git branch -vv

如果发现当前分支只是落后于远端，而且没有分叉：

git pull --ff-only

如果发现你在个人功能分支上，且更希望保持线性历史：

git rebase origin/main

为什么这对团队尤其重要

在团队协作里，最贵的代价常常不是“没同步”，而是“同步动作把历史改了，但本人并没有意识到”。
fetch-first 的价值就在这里：
它给你一个先理解再动作的缓冲带。

!不要把 pull 当成默认的“看看最新状态”命令

如果你只是想知道远端有没有前进，pull 往往动作过重。更保守的做法是先 fetch，看清楚再决定是否真的要改变当前分支。

常见误区

以为 pull 更省事，所以更适合初学者

恰恰相反。初学者更需要观察空间，而不是在一个命令里同时发生“下载 + 整合”。

只要 pull 成功，就说明历史一定干净

不一定。它可能已经帮你做了 merge 或 rebase，只是你没有立刻意识到。

先 pull，出了问题再说

更稳的方式是：先 fetch，把远端状态看清楚。

→同步前先问自己 3 个问题

1. 我现在只是想知道远端状态，还是准备真正整合？
2. 当前分支是共享分支还是个人分支？
3. 这次整合更适合 ff-only、merge、rebase，还是先不动？

团队建议

如果你正在设计团队 Git 规范，可以把下面这条写进约定：

• 开发分支同步前优先 fetch
• 共享分支默认 pull --ff-only
• 是否启用 pull.rebase 需要团队统一说明

接下来建议继续学什么

1. Sync before review
2. Feature branch collaboration
3. Hotfix and urgent fixes