嗨，我来给你拆解这三个Git配置选项到底会带来什么不同的结果，帮你选最适合你们两人协作的Flutter项目的方式～

1. git config pull.rebase false（合并策略，默认） #

这是Git默认的拉取行为，当你的本地分支和远程master分支出现分歧（两边都有对方没有的提交）时：

• Git会自动创建一个新的合并提交，把本地和远程的更改整合到一起
• 优点：完整保留所有提交历史，包括你和队友的提交顺序，不会改写已有的提交记录，对协作新手友好
• 缺点：提交历史里会多出来一些「Merge branch 'master' of ...」的合并提交，时间长了历史会显得比较杂乱

适合场景：你们两人经常同时在master分支提交代码，不想折腾历史改写，希望保留所有提交痕迹的情况。

2. git config pull.rebase true（变基策略） #

开启这个配置后，拉取远程代码时会执行变基操作：

• Git会先把你本地的新提交临时「存」起来，然后把远程master的最新提交拉到本地，最后把你之前的本地提交重新应用到远程最新提交的顶端
• 优点：提交历史会变成一条干净的线性记录，没有多余的合并提交，看起来更整洁
• 缺点：变基会改写提交历史——如果你的本地提交已经推送到远程过，再变基会导致远程和本地历史不一致，队友拉取时会遇到冲突麻烦

适合场景：你本地的提交还没推送到远程，或者你们两人各自在独立分支开发，合并到master前先变基，能让master分支历史更清爽。

3. git config pull.ff only（仅快进） #

这个配置是最严格的：

• 只有当你的本地分支是远程master分支的直接祖先（也就是你本地没有新提交，只有远程有更新）时，Git才会执行快进合并——直接把本地分支指针移动到远程最新的提交位置
• 如果本地有新提交，远程也有更新（出现分歧），Git会直接报错，不会自动进行合并或变基，需要你手动处理分歧（比如先手动变基或者合并）
• 优点：绝对保证提交历史的线性，不会有任何额外的提交
• 缺点：遇到分歧时需要手动介入，操作步骤会多一点

适合场景：你们希望master分支的历史完全线性，不允许任何合并提交，愿意手动处理分歧的情况。

额外补充：全局配置 vs 仓库配置 #

• 如果用git config --global开头，这个配置会应用到你本地所有的Git仓库
• 如果不加--global，只会对当前这个Bitbucket的Flutter项目生效
• 你也可以不用修改配置，每次拉取时用临时参数覆盖：比如git pull --rebase、git pull --ff-only，只对这次拉取操作生效

内容的提问来源于stack exchange，提问作者PeakGen