问Git在大提交和微提交中的性能

EN

“许多小的提交”将占用更多的空间，但这种差异可能不值得为失去的历史付出代价。

对包文件本身的影响将取决于以后有多少更改未更改。例如，如果后一次提交触及了先前提交也接触过的行，则在历史上一次大提交将看不到这些行的中间状态，因此在包文件中将没有对象来表示它们。

我无法想象在一个分支上提交的次数会减少或增加合并的复杂性；但我不能就此与权威人士交谈，因为我还没有确切地检查过典型的递归合并是如何完成的。我的理解是，从它们被合并(或拆分)的最后一点来看，它相当于一个diff3。在这种情况下，一个大的提交将不会比许多小的提交更有效率。

还有另一个方面要考虑，取决于时间。如果您正在处理一个分支，并且定期在您自己的提交之间合并上游分支，那么许多小的提交将产生较少的冲突，因为您将保持与上游分支的更好的均等，从而减少偏离它。这肯定会在合并的时候产生较少的问题。

垃圾收集在很大程度上不会受到影响，因为在这两种情况下，这两种方法都不存在悬空提交或松散对象。

总之，在处理文本时，包文件通常是足够有效的，以至于能够查看完整和纯正的历史记录的好处往往超过它所占用的额外空间的成本。