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