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

Question

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

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

Answer 1

原因为挤压提交:

我们不能再遵循该功能/错误修正的历史记录,以了解它是如何开发的,或者看到尝试但后来被替换的替代解决方案.(引自Mike Gerwitz的A Git恐怖故事.)
它使得git bisect无用.如果我们发现软件中的一个错误是由一个包含300个压缩提交的补丁引入的,那么我们就可以深入挖掘代码并调试自己,而不是让Git为我们找出问题.(引自Mike Gerwitz的A Git恐怖故事.)

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

Answer 2

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

如果您压缩了所有较小的提交，请考虑将表示为一次提交的差异。它是否正确传达了变革（或一系列变革）的全部要点？或者，中间提交中是否有某些内容传达了有关您正在做的事情的一些基本信息？

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

没有硬性规定。当考虑是否压制特定的提交时，询问它们是否产生了使整个变化不清楚的烟雾，或者它们是否产生了有助于解释整个变化的光。