commit - 我应该将小型开发承诺压缩成更大的开发承诺吗？

Question

关于如何压缩 git 和其他 DVCS 的提交存在（太多）问题，例如：

• 使用 Git 将我最后的 X 提交压缩在一起
• 如何将所有 git 提交压缩为一个？
• 在不合并的情况下将各种提交合二为一
• 有没有办法以非交互方式压缩大量提交？
• 我可以在 Mercurial 中压缩提交吗？
• 使用 Mercurial，我如何在推送之前将一系列变更集“压缩”成一个？
• ...

我的问题是，我想压缩提交吗？我应该保留详细的提交序列以显示功能是如何开发的，还是应该在功能完成后将它们压缩成一个，以保持历史更清晰？

Answer 1

压缩提交的原因：

• 更干净、更简单的历史。
• 更小的历史。克隆 repos 时的包袱更少。
• 删除“垃圾”提交，例如拼写错误修复。
• 提供改进提交消息的机会。

反对压缩提交的原因：

• 我们不能再跟踪该功能/错误修复的历史来了​​解它是如何开发的，或者查看尝试过但后来被替换的替代解决方案。（引自 Mike Gerwitz 的A Git Horror Story。）
• 它使 git bisect 无用。如果我们在软件中发现由 300 个压缩提交组成的单个补丁引入的错误，我们只能自己挖掘代码并调试，而不是让 Git 为我们找出问题所在。（引自 Mike Gerwitz 的A Git Horror Story。）

---

_{如果您不想给出自己的答案，请随时在此 wiki 答案中添加其他原因。}

Answer 2

这取决于您希望历史记录的粒度。如果在较小的提交中添加和删除了某些行，其他人稍后在提交历史中查看它们是否有用，或者它们只是会误导未来维护者的噪音？

考虑一下如果你压扁所有较小的提交，那么差异将被表达为一次提交。它是否正确传达了变更（或一系列变更）的全部内容？或者，中间提交中是否有一些东西可以传达一些关于你在做什么的重要信息？

如果您再次实施更改，是否有必要进行相同的中间提交？通常对我来说，这些中间提交要么是我在其上迭代构建整个更改的脚手架，在这种情况下，我可以通过挤压来丢弃它们。有时，一些中间提交修复了不需要成为提交历史的一部分的愚蠢错误或拼写错误，因此它们也可以被压缩。

没有硬性规定。在考虑是否压缩特定提交时，询问他们是否贡献了使整个更改不清楚的烟雾，或者他们是否贡献了有助于解释整个更改的光。

Answer 3

DVCS 的优势之一是能够为检查点和保留工作进行频繁的小提交，而不必发布它。

也就是说，我最近开始遇到我认为是 Mercurial 鼓励的默认“重写历史记录不好”立场的限制。将功能拆分为许多提交，并合并而不是变基，历史会很快变得非常混乱。正如DavidM 指出的那样，您采用哪种方法或方法组合将取决于您之后如何使用您的历史记录。我发现自己更频繁地使用 Mercurial 队列和变基等工具，以帮助保持历史更清晰。

我也对 Mercurial（目前）前沿的过时标记概念的潜力很感兴趣。通过存储原始变更集但允许它们被压扁的变更集取代，您似乎也可以吃掉蛋糕：清理历史记录，默认情况下仅显示最新的、合理大小的变更集 - 但始终具有选项解包一个功能并仔细检查其中的较小努力。