Git與Big Commits的性能與微小的提交相比

Question

所有的編碼標准和良好實踐都不談，Git 本身如何處理大型提交與小型提交。 例如，Git是否更聰明，分支合並（例如，更少的沖突）與任何一種情況，垃圾收集變得更有效，或類似的東西？ 或者有什么區別？

要清楚，我的意思是代碼從A修改為B的情況，“巨大的提交”只是將代碼從A直接改為B，而“小提交”有很多中間提交（比方說，對於每個小的特征變化），但最終在完全相同的B.

Answer 1

“許多小提交”將使用稍多的空間，但差異可能不值得付出歷史丟失的代價。

對packfile本身的影響取決於稍后未更改的更改數量。 例如，如果稍后的提交觸及先前提交也觸及的行，那么這些行的中間狀態在歷史中將不會在一次大提交時可見，因此packfile中將沒有對象來表示它們。

我無法想象分支上的提交數量會降低或增加合並的復雜性; 但由於我沒有仔細檢查遞歸的典型合並是如何完成的，所以我不能說權威。 我的理解是它等同於它們被合並（或拆分）的最后一點的diff3。 在這種情況下，一次大型提交的效率不會高於或低於許多小型提交。

根據時間安排，還有另一個方面需要考慮。 如果您正在處理分支，並定期在您自己的提交之間合並上游分支，那么許多小提交將產生更少的沖突，因為您將保持與上游分支更好的奇偶校驗，從而更少地偏離它。 當合並時，這肯定會導致更少的問題。

垃圾收集在很大程度上不受影響，因為在這兩種情況下，兩種方法都沒有固有的懸掛或松散的物體。

總而言之，在處理文本時，packfiles通常足夠有效，能夠查看完整和純粹的歷史記錄的好處往往超過所需額外空間的成本。