我认为 squash 是指 rebase n次提交，然后将其压榨。

所以，我的看法是，这是不同方法提供的。

1。使用reset

使用重置时，您正在做的是移动HEAD指向的内容。

  

将当前HEAD重置为指定状态。

     

重置将要做的第一件事是移动HEAD指向的内容。这与更改HEAD本身（签出操作）不同； reset移动HEAD指向的分支。这意味着，如果将HEAD设置为master分支（即您当前在master分支上），则运行git reset 9e5e6a4时会先将master指向9e5e6a4。

鉴于您可以将三个参数传递给命令--soft --hard --mixed，您可能会完全松散您的工作，或者可以在"Changes to be committed"中进行更改州。

这种方法的好处是简单，快捷。您告诉git您想要HEAD指向的位置，其余的更改（在本例中为3次提交）将被合并为一个大更改。然后提交并推送。很简单。

此方法的缺点是对南瓜的控制有限（因为这是南瓜的操作目标）。您看不到提交哈希，看不到3条提交消息，没有选择重新排序它们，重新措辞/修复任何提交的选项。

2。使用rebase

注意：在这里，我谈论的是一种交互式rebase，它的想法是正确压缩提交。

在git中以交互方式rebase进行操作时，会为您提供您已指定给rebase的所有提交的列表。它们是有序的，格式化的，在它们的下面，您可以为每次提交指定一组命令。因为我们对压扁感兴趣，所以我们可以选择压扁的承诺，其余的都可以用squash标记。

这允许我们做的是查看我们正在压缩的提交。我们可以阅读他们收到的消息，也可以查看我们的历史记录。在这一点上，我们可能会说我们实际上是想对它们重新排序，或者只是重新编码消息。 Git使我们拥有了想要的历史记录的更大灵活性（尽管有些人可能会告诉您，更改git历史记录是一件坏事，而且这种说法有时确实很有价值）。

但是，即使当我们只想压缩所有提交时，git也会使我们编写新的提交消息，并且我们可以从要压缩的提交中看到 all 所有提交消息。无需搜寻或记住以前的消息。

这种方法的缺点是使用git-interactive菜单可能会更加困难，并且可能需要花费更长的时间来进行squash。

我个人认为这两种策略都行得通，但是像rebase-ing的感觉 更适合挤压提交。这仅取决于您所处的情况。如果您认为通过重新设置和重新提交可能会更好，那么请继续。但是我认为使用互动式rebase可以避免您搞乱历史记录。

编辑我没有看到注释正确地指出了挤压不是不是将提交推送到您的遥控器的唯一方法。也许这是最直接，最简单的方法：）