区别在于：

• merge的 recursive 方面是merge操作如何得到结果，而不是你对结果做了什么。
• --squash，OTOH，是关于如何处理合并结果的。特别是，它创建了一个没有第二个父提交的新提交。如果你省略了--squash，则会创建一个合并提交（有两个父提交）。

你所展示的例子，一个在提交的线性历史中演化的特性，不需要递归合并策略。当你有一个包含交叉合并的历史时，递归方面就开始起作用了。

--r--o--F--o    <-- main
   \   /
     x          <-- lines cross (not a commit)
   /   \
--f--o--R--o    <-- feature

在一个点上，一个半完成的特性被合并到main中（产生F），在另一个点上，一个旧的main状态，比如说，一个标记的版本，被合并到feature中，产生R。
现在合并两个分支时，使用 * 递归 * 策略，因为两个分支有两个合并基，r和f。合并通过合并r和f来构建虚拟树，然后将该树用作最终合并的合并基。可以将其视为线交叉的地方，x .

这是两个不相关的正交设置。一个合并要么是递归的要么不是，要么是压缩的。所以你可以有

• 挤压和递归
• 压扁而不是递归
• 非压缩和递归
• 不压缩也不递归

要明白的是：合并会创建一个新的提交。考虑到这个事实：

• recursive是关于创建提交的 * 逻辑 *。它修改了普通的合并逻辑;这不是一个你通常需要做的修改，如果你做了，你可能需要考虑更多的事情来得到一个“正确”的答案，所以我建议不要使用它。
• 至于结果提交的 * 性质 *，普通合并创建合并提交，但挤压合并不会（挤压合并不是合并）。是否使用这是一种商业决策;我曾经遇到过这样的情况，我们被要求以这种方式合并，但在我看来，这是一件坏事，因为你会丢失历史，如果你的分支是长期存在的，你会冒着合并冲突大量增加的风险。在我看来，那些认为挤压合并使历史“更干净”的人只是错误地理解了什么是“干净”。