pull 的拉取策略是什么
git pull 其实是「取回远端」加「整合本地」两步，策略配置决定第二步怎么做：merge 会生成合并提交，rebase 会把本地提交重放到远端历史之上、保持线性。pull.rebase 就是控制这个默认行为的开关，取值 true、false、merges。它没有绝对优劣，取决于团队对历史形态的要求，但一定要在团队层面统一并写进文档，否则同一仓库会出现两种历史风格。
基本信息
| 配置键 | pull.rebase true | false | merges |
|---|---|
| 命令行覆盖 | git pull --rebase / --no-rebase / --rebase=merges |
| 相关配置 | pull.ff only 只允许快进 |
| 影响 | 决定分叉时生成合并提交还是线性历史 |
| 平台 | 任意 Git 客户端 |
典型使用场景
- 团队要求主干线性，避免无意义的合并提交
- 本地有未推送提交，需要把它们重放到最新远端之上
- 只希望在确实分叉时才变基，快进时保持原样
- 排查拉取后为何多出一条合并提交
- 统一团队环境，减少新人拉取时的反复询问
- 脚本中显式指定策略，不依赖个人配置差异
常用示例
常用示例
git config --global pull.rebase true # 全局默认变基拉取
git config --global pull.ff only # 只允许快进
git pull --rebase origin main # 单次变基拉取
git pull --rebase=merges origin main # 仅在分叉时变基
git pull --no-rebase origin main # 单次改用合并
git config --get pull.rebase # 确认当前设置取值含义
| 取值 | 行为 |
|---|---|
| true | 拉取时把本地提交变基到远端之上，历史保持线性 |
| false | 分叉时生成合并提交，保留双方拓扑 |
| merges | 快进时保持原样，只在需要整合时变基 |
未配置且可能分叉时，较新版本的 Git 会给出提示要求先选定策略；按团队规范一次性配置好，比每次临场决定更省事。
pull.rebase=true 会改写本地未推送提交的哈希，如果本地有分支或标签依赖于这些提交号，需要重新确认指向。