合并提交：保留分支中的所有提交，并将它们与基础分支

上的提交交错
合并挤压：保留更改但从历史记录中省略各个提交

Rebase：这会将整个特性分支移动到master分支的顶端，有效地将所有新提交合并到master分支中

有关here的更多信息

• 前两个图表来自About pull request merges on the GitHub Docs*

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

• git merge --squash abranch

将在目标分支上生成压缩提交，而不标记任何合并关系。（注意：它不会立即产生提交：您需要额外的git commit -m "squash branch"）
如果你想完全丢弃源分支，这是很有用的，从（模式取自SO问题）：

git checkout stable

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

致：

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一起使用。--commit和--squash * 永远 * 不可能一起使用。从Git 2.22.1（Q3 2019）开始，这种不兼容性被明确化：
参见commit 1d14d0c（2019年5月24日）by Vishal Verma ( reloadbrain ) .（由Junio C Hamano -- gitster --合并至commit 33f2790，2019年7月25日）

merge：用--squash拒绝--commit

以前，当提供--squash时，' option_commit '被静默删除。对于试图显式使用--commit覆盖squash的无提交行为的用户来说，这可能会令人惊讶。
git/gitbuiltin/merge.c#cmd_merge()现在包括：

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

• git rebase --interactive

在一个新的基础上回放你的部分或全部提交，允许你压缩（或最近的“修复”，见这个SO问题），直接进入：

git checkout tmp
git rebase -i stable

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

如果你选择压缩tmp的所有提交（但是，与merge --squash相反，你可以选择重放一些，压缩其他的）。
所以区别在于：

• squash不会触及你的源代码分支（这里是tmp），并在你想要的地方创建一个提交。
• rebase允许您在同一源分支上继续（仍然是tmp）：
• 新基地
• 清白的历史

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

现在我们有3个选项可以将功能分支的更改合并到主分支中：
1.* * 合并提交**
将保留功能分支的所有提交历史记录，并将它们移到主分支中
将添加额外的虚拟提交。
1.* * 重定基数并合并**
将功能分支的所有提交历史记录附加到主分支的前面
不会添加额外的虚拟提交。
1.* * 挤压与融合**
将所有功能分支提交分组为 * 一个提交 *，然后将其附加到主分支的前面
将添加额外的虚拟提交。
您可以在下面找到master分支将如何处理它们中的每一个。

在所有情况下：
我们可以安全地删除功能分支。

Merge squash将一个树（一个提交序列）合并成一个提交。也就是说，它将n个提交中所做的所有修改都压缩到一个提交中。
Rebasing就是rebasing，也就是为树选择一个新的基（父提交），也许这个术语更清楚：他们称之为移植是因为为树选择一个新的基础（父提交、根）。
当进行交互式重定基时，您可以选择挤压、拾取、编辑或跳过您要重定基的提交。
希望你说的够清楚！