git pull具体做了什么

Posted on Views:

Git 在执行 pull 时，本质上是做了两件事：fetch（下载远程代码）和 merge（合并到本地）。

  • fetch
  • merge

当你的本地分支和远程分支出现“分叉”时，Git 就需要知道用哪种方式来处理这些差异。这三个选项的核心区别在于 “提交历史的整洁度” 和 “对冲突的处理方式”：

1. merge (默认策略)

git config pull.rebase false
这是最传统的方式。如果本地和远程都有新的提交，Git 会自动创建一个新的 “Merge commit”，把两条线索连起来。

  • 优点： 真实记录了历史发生的顺序，保留了分支合并的轨迹。
  • 缺点： 如果团队频繁 pull，历史记录中会出现大量“Merge branch ‘main’ of…”的杂乱信息，导致提交线索变成“麻花状”。

2. rebase (变基策略)

git config pull.rebase true
这是一种“修剪”艺术。它会把你本地还没推送到远程的提交先“拿掉”，把远程的新提交同步下来，然后再把你刚才拿掉的提交重新按顺序接在最顶部。

  • 优点： 提交历史是一条干净的直线，没有任何多余的 Merge commit。
  • 缺点： 它改变了提交的哈希值（因为是“重新接上去”的）。如果操作不当（比如对已经推送到公有仓库的代码做 rebase），可能会让同事感到困惑。

3. ff-only (仅快进)

git config pull.ff only
这是一种“严格模式”。只有当本地没有任何新提交，可以直接“快进”同步远程代码时，才允许 pull 成功。

  • 优点： 绝对安全，不会自动产生任何合并行为。
  • 缺点： 只要你本地改了一行代码并提交了，git pull 就会报错。你必须手动决定是采用 merge 还是 rebase 来解决。

4.总结与建议

策略 提交历史 适用场景
Merge 复杂、网状 希望保留完整开发轨迹，不介意历史记录乱一点。
Rebase 简洁、直线 推荐。 追求极致整洁的历史记录，这也是目前大多数专业团队的选择。
FF-only 极简 极度谨慎，拒绝任何自动合并，完全手动控制。

操作建议：
如果你想要最干净的历史，建议执行：
git config --global pull.rebase true