抛开所有的编码标准和良好实践不谈，Git本身在技术上如何处理大提交与小提交。例如，在这两种情况下，Git 是否更智能地进行分支合并（例如更少的冲突），垃圾收集是否变得更有效率，或者类似的东西？或者有什么不同吗？
需要明确的是，我的意思是代码从 A 修改为 B 的场景，“巨大的提交”只是将代码从 A 直接更改为 B，而“小提交”有很多中间提交（比如，对于每个小的特征变化），但最终以完全相同的 B.
问问题
1086 次
1 回答
5
“许多小提交”将使用更多空间，但差异可能不值得为丢失的历史付出代价。
对包文件本身的影响取决于以后有多少更改未更改。例如，如果后来的提交触及了先前的提交也触及的行，那么这些行的中间状态在历史上不会在一次大提交时可见，因此包文件中将没有对象来表示它们。
我无法想象分支上的提交数量会减少或增加合并的复杂性；但我不能就此发表权威言论，因为我还没有确切地研究过典型的递归合并是如何完成的。我的理解是，它相当于从它们合并（或拆分）的最后一点开始的 diff3 。在这种情况下，一个大的提交不会比许多小提交的效率更高或更低。
还有一个方面需要考虑，具体取决于时间。如果你在一个分支上工作，并且在你自己的提交之间定期合并上游分支，那么许多小的提交将产生更少的冲突，因为你将与上游分支保持更好的奇偶性，从而更少地偏离它。当需要合并回来时，这肯定会导致更少的问题。
垃圾收集在很大程度上不会受到影响，因为在这两种情况下，两种方法都没有悬空提交或松散对象。
总而言之，包文件在处理文本时通常足够高效，因此能够查看完整且纯粹的历史记录的好处通常超过了它所占用的额外空间的成本。
于 2012-05-04T06:58:24.173 回答