Git 合并 - 压扁还是不压扁？答案

【问题标题】：Git merge - to squash or not to squash?Git 合并 - 压扁还是不压扁？
【发布时间】：2015-01-15 23:20:51
【问题描述】：

我目前正致力于在一个相当复杂的开发环境中实施 git 使用指南，虽然我认为我已经很好地设置了基础知识，但有一个问题特别想了解一下可能的。这不是一个纯粹的技术问题，因为它更多的是关于哪些可用选项最合适。

基本上，我倾向于一个与常见的“git 流”结构 (http://nvie.com/posts/a-successful-git-branching-model/) 非常相似的系统，但有一些例外是为了适应我们的开发环境。简而言之：

到目前为止，它确实帮助我们简化了开发并防止了项目之间的冲突。在这里引发一些争论的一个细节是；我们是否应该使用“--squash”选项将功能/票证分支合并回它们各自的起源？我有点喜欢这个，我喜欢它：

也许这些理由不够好，也许有充分的理由在这种情况下不使用“--squash”。有什么想法吗？

【问题讨论】：

【解决方案1】：

[S]我们是否应该使用 --squash 选项将功能/票证分支合并回它们各自的起源？

这完全取决于您希望回购历史的细粒度。请记住，通过提交消息进行的版本控制是一种代码文档形式。随意挤压当然不是好习惯。对于 hotfix 分支来说可能很好，但对于实质性的特性分支来说很少。

打个比方，想象一下，如果你向我借我的 Lost DVD 套装（即你克隆了我的仓库），我只是给你盒子，没有 DVD，然后告诉你

在这里，只需阅读封底上的系列摘要即可。这应该足以告诉您有关情节的信息。

因此，当您想要摆脱不必要的详细或不够独立的中间步骤时，请务必压缩您的提交，但不要使其模糊存储库的演变。

（我在this Twitter thread 中进一步讨论了这个问题。）

【讨论】：

这是有道理的。当然，我不是在谈论盲目地挤压任何分支。这将特别是关于我们认为的“票务分行”。我的主要考虑是它允许我确保进入“主”代码的每个提交都会有一个提交消息，清楚地指定它的票号。此外，由于我在这里看到的大多数票证通常不需要大量的提交来修复，所以我没有看到太多的理由在每个中间步骤经过测试、验证和合并后保留它。
我认为我们意见一致。我可以看到明确指定相关票号的提交消息的吸引力；你是对的，大多数票证不需要那么多提交，所以在挤压过程中不会丢失太多细节。我想你的问题的答案很大程度上取决于具体情况。总之，壁球，但有洞察力。
或者根本不要压缩，并确保在每个提交消息中输入一个票号。或者更改您的工具，以便它可以从其他地方推断票号。
@jub0bs 如果你用 squash 说一个很好的详细的提交信息，然后在页脚留下你压缩过的分支的引用怎么办？这样你就可以在你的开发中有一个良好的有序历史，如果你想查看更多细节，你可以查看功能分支的历史
@JordanKanchelov 这仍然会阻止我逆转原子更改。这就是为什么我不喜欢壁球。

【解决方案2】：

不要压扁：小提交非常有用，特别是对于以后使用git bisect 跟踪错误，而且无论如何你不想改变历史记录。只需使用合并提交 (git merge --no-ff) 来保持历史的有序性。

【讨论】：

当有很多嘈杂的无意义的中间提交时，跟踪错误变得更难而不是更容易。您想要进行一个有凝聚力的提交，以表示从一个分支到另一个分支的大量更改是有意义的。在应用每个单独的提交后，项目应该构建并处于合理状态。
@Sammi：“在应用每个单独的提交后，项目应该构建并处于合理状态。”同意。 • “当有很多嘈杂的无意义的中间提交时，追踪错误变得更难而不是更容易。”我不提倡无意义的提交，但我提倡较小的提交。由于git bisect 使用提交作为其粒度单位，较小（有意义的）提交使得跟踪错误更容易。我同意每次提交都应该是一个有凝聚力的已知良好状态，但有时这意味着只更改 3 行代码。