我应该把小型的开发工作压缩成更大的吗？

Question

关于如何压缩git和其他DVCS的提交有很多问题，例如：

• Squash my last X commits together using Git
• How to squash all git commits into one?
• Joining various commits in one without merging
• Is there a way to squash a number of commits non-interactively?
• Can I squash commits in Mercurial?
• With Mercurial, how can I "compress" a series of changesets into one before pushing?
• ...

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

Answer 1

压缩提交的理由：

• 更清洁，更简单的历史。
• 历史较小。克隆回购时减少行李负担。
• 删除＆＃34;垃圾＆＃34;提交，例如拼写错误修复。
• 提供改进提交消息的机会。

反对压缩提交的原因：

• 我们不能再遵循该功能/错误修正的历史记录，以了解它是如何开发的，或者看到尝试但后来被替换的替代解决方案。 （引自Mike Gerwitz＆＃39; s A Git Horror Story。）
• 它使git bisect无用。如果我们发现软件中的错误是由一个由300个压缩提交组成的补丁引入的，我们只需要挖掘代码并调试自己，而不是让Git可能为我们找出问题。 （引自Mike Gerwitz＆＃39; s A Git Horror Story。）

---

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

Answer 2

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

如果你压扁了所有较小的那些，请考虑将表示为一次提交的差异。它是否正确地传达了变化的全部要点（或一系列变化）？或者，中间提交中是否存在某些关于您正在做什么的基本信息？

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

没有硬性规定。在考虑是否要压制特定的提交时，请询问它们是否会产生烟雾，使整个变化不明确，或者它们是否有助于解释整个变化的光线。

Answer 3

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

那就是说，我最近开始遇到我认为是Mercurial所鼓励的默认“重写历史不好”的限制。随着功能分成许多提交，并且合并而不是重新定位，历史可以非常快速地变得混乱。作为DavidM points out，采用哪种方法或方法组合，取决于您之后如何使用历史记录。我发现自己更频繁地使用像Mercurial队列和rebase这样的工具来帮助保持历史清洁。

我也对Mercurial（目前）bleeding-edge obsolescence marker concept的潜力感兴趣。通过存储原始变更集但允许它们被一个被压扁的变更集取代，看起来你可以拥有你的蛋糕并吃掉它：干净的历史记录只有默认显示的最新的，合理大小的变更集 - 但总是有选项打开一个功能并仔细检查进入它的较小的努力。