当git在git pull期间必须协调本地分支中的更改时，这两个设置都作用于git pull的行为，但它们并不旋转同一个旋钮。

• pull.ff可以设置为false | true | only。

它匹配cli选项：--no-ff | --ff | --ff-only，如果在命令行中传递了这些选项中的任何一个，则会忽略config设置。
如果设置为only，如果远程分支不在本地分支的正前方，git pull将拒绝执行任何操作，因此pull.rebase设置永远不会生效--除非配置设置被命令行上的标志覆盖。

• pull.rebase可以设置为false | true | interactive | merges。

它与cli选项--rebase[=false|true|merges|interactive]匹配，再次：如果在命令行中传递了这些选项中的任何一个，则忽略config设置。
如果它被设置为“使用rebase来合并更改”（例如：true|interactive|merges），那么声明--ff或--no-ff的设置就没有任何效果--反正不会有合并。

• 我该用什么 *

这个问题取决于上下文-例如：如果您的员工的工作流特别支持某个操作，请将默认值设置为该操作;如果您习惯于特定的操作序列，请将默认值设置为您的用法。
我不会回答你的问题，我会描述我是如何工作的：
我个人并不喜欢使用git pull，因为你需要一次性地“从中央存储库中获取你不知道的更改，并将它们与你的工作合并”，而没有机会查看两个步骤之间的更改。
我一般跑：

1. git fetch
2. git log --graph --oneline origin/master my/branch（例如：检查我感兴趣的远程分支的状态）
   1.运行git rebase origin/master或git merge origin/master（我们碰巧有一个支持rebase的工作流，但无论如何：我已经知道这个动作有多复杂了）
   与git pull的区别在于，在步骤3，我可以做：

• 合并或变基远程分支的 intermediate 提交，或我自己分支的中间提交，
• cherry-pick一个特定的commit来看看它会引入什么混乱，
• 在 * rebased/merging之前编辑我的分支（一种常见情况：删除那个提交，它做的事情几乎和master上添加的bug修复一样）
• ...

我还为pull --ff-only设置了一个别名，因为这个别名是“无害的”（例如：你知道git不会弄乱你的代码，如果你运行它，它要么做一些琐碎的事情，要么停下来说“这不是快进”），并用它来更新不是我的分支。

如果可能，两个命令都快进
实际上，当设置为only时，如果当前分支的尖端不能快进，pull.ff将 * 拒绝 * 拉取。
而pull.rebase只是指示pull进行合并（快进与否）。
就我个人而言，我总是使用git config --global pull.rebase true，以便在刷新的远程跟踪分支上重基（重播）我的本地提交（尚未推送）。
有什么意义的相似的命令
因为这两种设置实现的目标不同：

• 将pull.ff设置为only不允许快进pull：这是在 mergepull上要做事情。
• 如果pull.rebase设置为true，则pull.ff无关紧要：if是关于在pull上做什么（合并？还是变基？）