我与一个使用“合并工作流程”的小团队合作，我们最近根据Sandofsky 的文章切换到了“rebase 工作流程” 。
我们当前的工作流程：
在 rebase 特性分支之后，我们将其压缩并合并到我们的 master 中。如果我们改用 --no-ff 会发生什么？git merge --squash和 和有什么不一样git merge --no-ff？
--squash创建包含所有合并更改的单个提交（它将整个合并分支的历史压缩到一个提交中）。--no-ff还合并到一个分支中，创建一个合并提交并保留合并分支的整个历史记录。
git merge --squash创建一个单一的提交，该提交应用您将应用正常的所有更改merge。因此，它将您要带到分支的所有提交合并到一个提交中。
git merge --no-ff防止快进 - 如果源和目标没有分歧，只需将分支指针移动到较新的提交的操作。因此，使用--no-ff你保证你将有一个新的提交，其父母将是你的当前HEAD和feature_branch负责人。
在log这两种情况下，在第一个场景中，您只会看到一行提交，每个提交都是一个feature_branch 摘要，而在第二个场景中，您会看到很多分支，每个分支一个feature_branch，并且全部master再次加入。
由于git merge --squash基于这些生成一个新的提交feature_branch，它们是不同的提交，所以如果你feature_branch单独发布，你可能会遇到麻烦 - 比如说，你可以git merge --squash feature_branch多次而不git理解它，但你会遇到冲突。
最大的不同在于你的分支历史。使用 --squash，您将拥有一个线性分支历史记录，其中分支上的每个提交都包含该提交的合并执行的所有更改。使用 --no-ff，您将有一个不同的分支历史记录，其中包含合并提交，显示两个分支与多个父级一起出现的位置，并且父级提交将包含所做的实际更改。
就个人而言，我更喜欢 --squash 方法，因为它可以更容易地识别更改的来源（因为更改是在实际的压缩提交中，而不是父提交中）。缺点是它是一个独特的提交，而不是提交历史，因此如果您继续在该分支上进行开发并进行另一个 squash 提交，您将获得另一个包含该分支的整个更改历史的提交。这会使识别更改的来源变得更加困难，因为看起来相同的更改是在两个不同的提交中进行的。解决方案是在执行 squash 提交后删除该分支，并且任何更改或改进都应位于 develop 的新分支中，该分支包含其历史中的 squash 提交。