7

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

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

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

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

  1. git merge --squash产生一个非合并提交。因此，Git 不会将您要合并的提交识别为合并基础。git merge --squash当 1) 在分支 X 上将 A 更改为 B，2)从分支 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？

4

2 回答 2

4

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

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

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

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

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

因此，它可能并非在所有情况下都有用，但肯定有一些情况下使用起来非常好。最明显的一个是在本地分支进行 WIP 提交，然后将它们推送到其他开发人员可以看到的地方。分支 Y 上所有混乱的 WIP 提交都是由同一作者提交的，没有其他人会看到分支 Y，因此可以在合并后将其重新定位到 X 上，或者即使您不感兴趣，也可以完全丢弃 Y在 WIP 历史中。

于 2019-07-22T11:40:02.057 回答
3

这个例子似乎是故意设计来展示缺点的。如果 squash-merge 适用于 Branch X，则第 3 步和第 4 步可能是git merge BranchX -n && git commit --amend，或者git checkout BranchA && git reset HEAD^ --hard && git merge BranchX --squash && git commit相反，好像 BranchX 是 squash-merge 而不是被合并两次。

messy WIP commits通常在本地临时主题分支上。这些提交的作者通常是执行 squash-merge 的同一个人。这些提交以更随意的方式创建为草稿，稍后 squash-merge 可以将它们转换为单个优雅的提交，就好像它是在目标分支上精心创建的一样。

有时，为了保持线性历史，人们可能会将一个正式分支压缩合并到另一个分支，而不是执行真正的合并。压扁的提交是由不同的作者创建的。捐款可能会被盗。但在实践中，原始分支和带有提交消息的提交哈希按照约定保存在新提交的消息中，合并后的分支也被保留，以便人们了解 squash-merge 提交的来源并能够查看原始提交。

于 2019-07-22T12:32:23.293 回答