合并提交:保留分支中的所有提交，并将它们与基本分支上的提交交叉

合并压缩:保留更改，但从历史记录中省略个人提交

Rebase:这将整个特征分支移动到主分支的顶端，有效地将所有新提交合并到主分支中

更多信息请点击这里

前两张图来自GitHub Docs上的关于拉请求合并

让我们从下面的例子开始:

现在我们有3个选项来合并特征分支的变化到主分支:

合并提交 将保持所有的提交历史的特征分支和移动到主分支 将增加额外的虚拟提交。 重组和合并 将在主分支的前面附加特征分支的所有提交历史 不会添加额外的虚拟提交。 压缩和合并 是否将所有的特性分支提交归为一个提交，然后将其追加到主分支的前面 将增加额外的虚拟提交。

您可以在下面找到主分支将如何处理它们中的每一个。

在所有情况下: 我们可以安全地删除特征分支。

git merge -squash和git rebase -interactive都可以生成一个“压缩”提交。但它们的用途不同。

Git合并—压缩分支

将在目标分支上产生一个压缩提交，而不标记任何合并关系。 (注意:它不会立即产生一个提交:你需要一个额外的git commit -m "squash branch")

如果你想完全抛弃源分支，这是很有用的，从(schema taken from SO question):

git checkout stable

          X               stable
         /
a---b---c---d---e---f---g tmp

to:

git merge --squash tmp
git commit -m "squash tmp"


# In the following graph, G is c--d--e--f--g squashed together

          X-------------G stable
         /
a---b---c---d---e---f---g tmp

然后删除TMP分支。

注意:git merge有一个——commit选项，但是不能和——squash一起使用。永远不可能同时使用——提交和——挤压。 从Git 2.22.1(2019年Q3)开始，这种不兼容性是明确的:

参见Vishal Verma (reloadbrain)提交1d14d0c(2019年5月24日)。 (由Junio C Hamano合并- gitster -在提交33f2790, 2019年7月25日)

合并:拒绝-提交-挤压

之前，当提供——squash时，'option_commit'是静默的 下降了。这可能会让试图重写的用户感到惊讶 squash的不提交行为显式使用——commit。

Git / Git builtin/merge.c#cmd_merge()现在包括:

if (option_commit > 0)
    die(_("You cannot combine --squash with --commit."));

Git rebase—交互式

在一个新的基础上重放你的一些或所有提交，允许你压缩(或者最近的“修复”，看这个SO问题)，直接到:

git checkout tmp
git rebase -i stable

   stable
      X----------------G tmp
     /
a---b

如果您选择压缩tmp的所有提交(但是，与merge -squash相反，您可以选择重放一些，并压缩其他)。

所以区别在于:

Squash不会触及你的源分支(这里是tmp)，而是在你想要的地方创建一个单独的提交。 Rebase允许你继续在同一个源分支上(仍然是tmp): 新基地 清白的历史

合并挤压将树(一系列提交)合并为单个提交。也就是说，它将n次提交中所做的所有更改压缩到一次提交中。

重基就是重基，即为树选择一个新的基(父提交)。也许这种变化的术语更明确:他们称之为移植，因为它只是:为树选择一个新的地面(父提交，根)。

当做一个交互式的重基时，你可以选择压缩，选择，编辑或跳过你要重基的提交。

希望你讲清楚了!

合并提交:保留分支中的所有提交，并将它们与基本分支上的提交交叉

合并压缩:保留更改，但从历史记录中省略个人提交

Rebase:这将整个特征分支移动到主分支的顶端，有效地将所有新提交合并到主分支中

更多信息请点击这里

前两张图来自GitHub Docs上的关于拉请求合并