所有编码标准和良好实践都不谈，Git 本身在技术上如何处理大型提交与小型提交。例如，Git是否更聪明，与其中任何一种情况的分支合并（例如更少的冲突），垃圾收集变得更有效，或类似的东西？或者有什么不同吗？
要清楚，我的意思是代码从A修改为B的情况，“巨大提交”只是将代码从A直接更改为B，而“小提交”有很多中间提交（比如说，对于每个小的特征变化），但最终会在完全相同的B中结束。
答案 0 :(得分：5)
“许多小提交”将使用稍多的空间，但差异可能不值得为历史丢失付出代价。
对packfile本身的影响取决于稍后未更改的更改数量。例如，如果稍后的提交触及先前提交也触及的行，那么这些行的中间状态在历史记录中将不会显示一次大提交，因此packfile中将没有对象来表示它们。
我无法想象分支上的提交数量会降低或增加合并的复杂性;但由于我没有仔细检查递归的典型合并是如何完成的，所以我不能说权威。我的理解是它等同于它们被合并（或拆分）的最后一点的diff3。在这种情况下，一次大型提交的效率不会高于或低于许多小型提交。
根据时间安排，还有另一个方面需要考虑。如果您正在处理分支，并定期在您自己的提交之间合并上游分支，那么许多小提交将产生更少的冲突，因为您将保持与上游分支更好的奇偶校验，从而更少地偏离它。当合并时，这肯定会导致更少的问题。
垃圾收集在很大程度上不受影响，因为在这两种情况下，两种方法都没有固有的悬挂或松散的物体。
总而言之，在处理文本时，packfiles通常足够有效，能够查看完整和纯粹的历史记录的好处往往超过了额外空间的成本。