Git的大性能提交對微小的承諾

Question

所有的編碼標準和良好實踐談不談，怎麼混帳本身技術上處理龐大提交VS小的提交。例如，Git是否聰明，分支合併（例如更少的衝突）與任何一種情況，垃圾回收變得更有效率，還是類似的？或者有什麼區別？需要說明的是，當代碼從A修改爲B時，「巨大承諾」只是直接將代碼從A更改爲B，而「小承諾」有很多中間代碼承諾（比如，每個小功能變化），但最終在完全相同的B.

Answer 1

的「許多小提交」最終將使用稍多的空間，但不同的是很可能不值得付出失去歷史價格。

本身將取決於許多變化是如何對打包文件的影響後未改變。例如，如果稍後的提交涉及早期提交也觸及的行，那麼這些行的中間狀態在歷史中將不會顯示，只有一個大提交，因此packfile中不會有對象來表示它們。

我無法想象，提交的分支上的數量將減少或增加合併的複雜性;但由於我沒有仔細研究典型的遞歸合併是如何完成的，因此我無法用權威說話。我的理解是，它等同於它們合併（或拆分）的最後一個點的diff3。在這種情況下，一個大的承諾不會比許多小的承諾更有效率。

還有另一個方面來考慮，這取決於定時。如果你在一個分支上工作，並且經常在你自己的提交之間合併上游分支，那麼許多小的提交將會產生更少的衝突，因爲你會保持與上游分支更好的平等，並且因此偏離較少。當它合併時，這肯定會導致更少的問題。

垃圾收集。將基本上不受影響，因爲在這兩種情況下，沒有懸掛提交或在任一方法中固有鬆散物。

總而言之，當處理文本時，包文件通常足夠高效，能夠查看完整且純粹的歷史記錄的好處常常超過所需額外空間的成本。