问pull.rebase假与pull.ff的真实区别是什么？

EN

虽然这两种设置都取决于当git在git pull期间必须协调本地分支中的更改和更改时git pull的行为，但它们不会转动相同的旋钮。

• pull.ff可以设置为false | true | only。它匹配cli选项：--no-ff | --ff | --ff-only，如果在运行git pull时传递这些cli选项中的任何一个，则忽略配置设置。

如果设置为only，则如果远程分支不在本地分支的前面，则git pull将拒绝执行任何操作，因此pull.rebase设置永远不会启动--除非配置设置被命令行上的标志覆盖。

• pull.rebase可以设置为false | true | interactive | merges。它与cli选项--rebase[=false|true|merges|interactive].

匹配。

如果设置为“使用重基组合更改”(例如：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的不同之处在于，在第三步，我可以：

master)

• ...

• 合并或重基远程分支的中间提交或我自己的分支的中间提交(

• )--选择一个特定的提交来查看它会导致什么混乱，

• 会在重基/合并之前编辑我的分支(一个常见的情况是:删除该提交，该提交与在上添加的see几乎相同。)

我还为pull --ff-only设置了一个别名，因为这个别名是“无害的”(例如:如果您运行它，git不会搞乱您的代码，它要么会做一些琐碎的事情，要么会停下来说“这不是快速转发”)，并使用它来更新不属于我的分支。

如果可能的话，

两个命令都是快速转发的。

实际上，当设置设置为pull.ff时，如果当前分支的尖端不能被快速转发，则only将拒绝提取。

而pull.rebase只是简单地指示pull进行合并(快进与否)。

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

类似的命令有什么意义？

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

pull.

• set pull.ff to only不允许快速转发pull：这是在合并pull.ff上应该做的事情。

• 如果pull.rebase设置为true，那么pull.ff并不重要:如果是关于在pull上做什么(合并？或重基？)