pull.rebase false 和 pull.ff true 有何区别？

Question

使用上有什么区别吗

git config pull.rebase false     # merge (the default strategy)

和

git config pull.ff true

如果可能的话，两个命令都会快进，如果不合并的话。

我应该使用哪个配置？

Answer 1

虽然这两个设置都影响git pullgit 在 git 期间必须git pull协调本地分支中的更改与上游更改时的行为方式，但它们不会转动相同的旋钮。

• pull.ff可以设置为false | true | only.
  它与 cli 选项 : 匹配--no-ff | --ff | --ff-only，如果在命令行上传递这些选项中的任何一个，则配置设置将被忽略。

如果设置为only，git pull如果远程分支不是直接位于本地分支之前，将拒绝执行任何操作，因此该pull.rebase设置永远不会生效。

• pull.rebase可以设置为false | true | interactive | merges.
  它与 cli 选项匹配--rebase[=false|true|merges|interactive]，并且再次强调：如果在命令行上传递这些选项中的任何一个，则配置设置将被忽略。

如果它被设置为“使用 rebase 来组合更改”（例如：）true|interactive|merges，则说明--ff或的设置--no-ff无效 - 无论如何都不会进行合并。

我应该用什么？

这个问题取决于上下文 - 例如：如果您的工作有一个专门支持某个操作的工作流程，请将默认值设置为该操作；如果您习惯了特定的操作顺序，请根据您的使用情况设置默认值。

我不会回答你的问题，而是描述我的工作方式：

我个人不喜欢使用git pull，因为你一次性“从中央存储库中获取你不知道的更改，并将它们与你的工作合并”，而没有机会检查两个步骤之间的更改。

我通常运行：

1. git fetch
2. git log --graph --oneline origin/master my/branch（例如：检查我感兴趣的远程分支的状态）
3. 运行 或git rebase origin/master（git merge origin/master我们碰巧有一个有利于 的工作流程rebase，但无论如何：我已经知道该操作将有多复杂）

不同之处git pull在于，在步骤 3 中，我可以执行以下操作：

• 合并或变基远程分支的中间提交，或我自己分支的中间提交，
• 挑选一个特定的提交来看看它会带来什么混乱，
• 在变基/合并之前编辑我的分支（一种常见情况：删除该提交，它的作用与 master 上添加的错误修复几乎相同）
• ...

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

Answer 2

如果可能的话，两个命令都会快进

实际上，当设置为 时，如果当前分支的尖端无法快进，pull.ff将拒绝only拉动。

虽然pull.rebase只是指示pull进行合并（快进或不快进）。

就我个人而言，我总是使用它git config --global pull.rebase true来在刷新的远程跟踪分支之上重新设置（重播）我的本地提交（尚未推送）。

类似的命令有什么意义

因为两种设置实现不同的目标：

• 设置pull.ff为only不允许快进：这是合并pull时要执行的操作。 pull

• ifpull.rebase设置为 true，那么并不重要：if 是关于在（合并？或变基？）pull.ff上做什么pull