“git merge --squash”的正确用例是什么？

Question

有些人喜欢git merge --squash的原因如下：

压缩到单个提交让您有机会清理杂乱的 WIP 提交，并为您正在合并的更改提供一个很好的理由。

https://coderwall.com/p/qkrmjq/git-merge-squash

但是，我认为有一些缺点超出了制作干净历史的优点。

1. git merge --squash产生一个非合并提交。因此，Git 不会将您正在合并的提交识别为合并基础。当 1) 在分支 X 上将 A 更改为 B，2)git merge --squash从分支 X 到分支 Y，以及 3) 在分支 X 上将 B 更改为 A（还原），以及 4) 将 X 合并到 Y 时，这会导致不需要的合并结果。 在第 4 步之后，在分支 Y 上，从 A 到 B 的更改不会恢复。这里，这是 3 路合并，因此比较从分支 X 到合并基的差异和从分支 Y 到合并基的另一个差异。前者包括没有变化，后者包括从A到B的变化，所以合并结果包括从A到B的变化。

2. 提交作者被覆盖，这会丢弃贡献。git merge --squash产生一个名为 who did 的新提交git merge --squash。当然，提交内容来自原始提交。这听起来像是在窃取贡献。这成为https://github.com/Microsoft/winfile/pull/42#issuecomment-380681627 中的一个问题

什么是正确的用例git merge --squash？

Answer 1

的正确用例是什么git merge --squash？

1. 如果项目的政策不允许在其主分支上进行合并提交，那么创建非合并提交这一事实就不是问题（无论如何，这正是您想要的）。

   如果您不打算在合并后再次使用 Y 分支（例如，因为 Y 是一个短期功能分支，并且该功能现在已合并到 X），那么未来来自 Y 的合并具有“错误”合并是无关紧要的-根据。无论如何，您将来不会对 Y 进行任何合并。

   或者，如果您在合并后在 X 上重新设置分支 Y 的基础，那么将来来自 Y 的合并将具有正确的合并基础。

2. 如果分支上的所有提交都是同一作者，那么第二个问题也不存在。

因此，它可能并不适用于所有情况，但肯定在某些情况下它完全可以使用。最明显的一个是本地分支，在将 WIP 提交推送到其他开发人员可以看到的地方之前。分支 Y 上所有混乱的 WIP 提交都是由同一作者完成的，没有其他人会看到分支 Y，所以合并后在 X 上重新建立基础是可以的，或者如果你不感兴趣，也可以完全丢弃 Y在 WIP 历史中。