大型項目的git歷史數據

Question

我是一個Git的新手，並試圖理解這些原則。正如我在Git中所瞭解的，每個文件都按照Git Book以及this post完全存儲。然而，git book還指出了git gc，它壓縮二進制文件並計算文本文件的差異，這種說法似乎與git存儲完整文件的第一點相矛盾。

1）有人可以解釋哪一個是正確的？如果git gc確實計算了部分差異，並且它恰好在很長一段時間後運行，這是否會確保所有差異都是從基本版本創建到所有分支？如果git gc沒有定期運行，這是否意味着很多計算時間？

2）考慮到像Android這樣的項目有大量的源文件和資源文件，這似乎表明git會在每次提交時大小都會增大。當開發者提取Android源代碼時，如果它爲所有源文件和二進制文件提取整個歷史記錄，是否會佔用大量空間？我在這裏錯過了什麼嗎？這是如何長期持續的？

Answer 1

Git是一個花哨的內容尋址文件系統。 理論上，它存儲每個修訂中每個文件的完整內容，並且每個blob（文件內容）都有一個可以被檢索的文件。在這種情況下，git實際上有能力將文件存儲爲類似文件的diff（通常是以前的版本，但不一定必須），但是這完全發生在git存儲文件的最低級別。 git用戶不僅不必考慮它，即使大部分git 工具都不必考慮它。

至於大小的問題，因爲有在「混帳filesstem」各種形式的壓縮，因爲他們是很有效的，包含項目的整個歷史上.git目錄通常是小於代碼的單一結帳，直到項目達到數十萬次提交。

如果一個存儲庫變得難以管理的龐大，有可能（藉助像git graft這樣的工具）將項目的歷史拆分成不同的存儲庫，沿着新/古歷史或活動/存檔分支或其他東西像那樣。

Answer 2

git gc用於清理/壓縮存儲庫中的鬆散對象。它通過打包對象（文件/樹/提交的每個完整狀態）來完成此操作。 diff可以從以前的文件創建，也可以來自完全不相關的文件，但具有類似的內容git。

爲了解決問題2，如前所述，git的確收拾對象。儘管從概念上講，每個文件都有一個完整的副本，但是在運行gc時，它們會被打包。至於存儲二進制文件，version control in general is not the best first choice.

Answer 3

方式git gc計算存儲的差異並不一定與文件的歷史有關。事實上，我記得在某個地方讀書，但目前找不到參考資料，可能會選擇更多最近「基地」修訂版，因爲這些是您最有可能簽出的版本。如果您有10,000個修訂版並正在檢出最新版本，則不需要將10,000個差異版應用於修訂版1以獲取所需的版本。

某些操作會自動運行git gc。 pull就是其中之一，所以在運行它之間不太可能會很長時間。沒有什麼能夠阻止你在每次提交之後運行它，如果你這麼傾向。本質上，這是其他版本控制系統在幕後執行的，也是git如此之快的主要原因之一。