git 在执行 git pull 时会先 fetch 远端，再把远端分支合到当前分支。你看到的提示：

1
2

hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase

本质是在告诉你：pull 到底是“合并”（merge）还是“变基”（rebase）。这两者结果都能拿到最新代码，但历史形态与冲突处理方式完全不同。

1. merge：保留历史分叉，产生合并提交

当 pull.rebase=false（默认）时：

1
2
3
4
5
6
7
8
9

A---B---C (main, 本地)
     \
      D---E (origin/main, 远端)

# git pull

A---B---C---M (main)
     \   /
      D-E

• git pull 会产生一个 merge commit（合并提交）。
• 保留“分叉—合并”的真实历史。
• 对团队追踪历史很清晰，但提交图会更“复杂”。

适合场景

• 想保留真实分支演进历史。
• 团队习惯显式 merge commit。
• 你不介意日志里出现合并点。

2. rebase：改写本地提交，历史更线性

当 pull.rebase=true 时：

1
2
3
4
5
6
7

A---B---C (main, 本地)
     \
      D---E (origin/main, 远端)

# git pull --rebase

A---B---D---E---C' (main)

• 本地未推送的提交（C）会被“摘下来”，先应用远端 D/E，再把 C 重新放上去。
• 历史变成一条直线，更干净。
• 会改写本地提交哈希（C 变成 C’）。

适合场景

• 喜欢干净、线性的提交历史。
• 本地提交还没推送到远端。
• 常用 rebase 保持主干“无合并点”。

3. 冲突处理的差异

• merge 冲突：一次性解决冲突，提交一个 merge commit。
• rebase 冲突：每个提交逐个 rebase，可能多次冲突，需要多次 git rebase --continue。

总结：

• merge 冲突一次性解决，但历史更乱；
• rebase 冲突可能多次解决，但历史更清晰。

4. 常用配置方式

只想对当前仓库生效：

1

git config pull.rebase true

想全局生效：

1

git config --global pull.rebase true

当然你也可以临时指定：

1
2
3

git pull --rebase      # 本次使用 rebase

git pull --no-rebase   # 本次使用 merge

5. 简单结论

• 协作分支/公开历史：倾向 merge，避免重写公共历史。
• 个人分支/保持主干整洁：倾向 rebase。

一句话总结：

merge 保留真实历史；rebase 改写历史换来线性日志。

如果你习惯干净的日志，推荐开启 pull.rebase=true；如果更重视历史真实，就保持默认的 merge 更稳妥。