本地回購和bitbucket的大小差異

Question

我有一個本地倉庫。 我用du -csh <foldername>命令檢查了.git文件夾的大小。 是168 mb。 我把它推到了我的bitbucket倉庫中。 我檢查了要下載的存儲庫大小，只有134 mb。

這怎么可能？

Answer 1

首先，讓我們解決整個存儲庫的大小。 （跳到第二個標題部分以跳過此部分。）

通常，“純服務器”存儲庫是Git所謂的裸存儲庫，即沒有工作樹的存儲庫。

請記住，在任何 Git倉庫^，1你有：

• 每一次提交，都以僅Git的形式存儲，此外
• 與這些提交相關的每個文件 ，也都以僅Git的形式存儲，以及
• 一些雜項開銷數據（標簽，樹，參考名稱，“信息”，hook等）。

這^2個文件都不具有“您通常在計算機上使用的文件”的形式，因此，如果您打算對提交進行任何操作，而不是將其發送到另一個Git，則可能需要一個工作樹。 服務器上的--bare信息庫大多數情況下只是將提交轉移到其他Git（接收和發送），因此保留當前提交的工作副本既浪費空間，又實際上適得其反。

由於服務器省略了工作副本，因此通常應該期望服務器端的裸存儲庫小於客戶端的非裸存儲庫。 因此，您觀察到的結果應該完全毫不奇怪。 令人驚訝的是 ，有時，服務器的大小倉庫越大 。 有許多可能的原因，最有可能的原因是壓縮/垃圾收集代碼尚未在服務器上運行。 在某些情況下，您可能需要從運行服務器的任何人那里獲得幫助。 參見，例如， 如何減少Bitbucket上的git repo大小？ 完整的細節迅速深入到打包文件格式，增量壓縮窗口，備用對象目錄等雜草中，例如GitHub之類的站點大量使用后者，以防止派生占用太多空間，等等。

---

¹這有意忽略淺分支或單分支克隆，這些克隆會在指定位置截斷歷史記錄，因此會忽略一些或許多提交和文件。

²實際上，Git的許多內部文件是純文本的，但許多文件不是​​純文本的，在任何情況下，如果要編寫自己的代碼以與Git一起使用，則通常應使用Git所謂的管道命令來操縱它們。 使用提供的API（管道命令）可以使您免受以后的更改，這些更改旨在使Git更好，更快地工作等。

---

但是您的.git只是裸倉庫

您將.git文件與他們的下載進行了比較。 這些都不是，也沒有工作樹，那么為什么.git目錄更大？

現在，我們必須至少進入一點雜草。

首先要知道的是，每個Git 對象的 Git都有兩種形式：每個提交，每個“ blob”（文件）以及每個帶注釋的標記和樹。 其中之一是寬松格式，僅由zlib定義。 另一個在壓縮文件中 。

當您在Git存儲庫中工作時，會創建新的松散對象。 Git最終確定有太多松散的物體占用了太多的空間，並將其打包。 這使得它們的檢索速度較慢-必須找到它們並解壓縮它們，而不是直接將它們收集起來並重新充氣-但現在它們占用的空間更少。

其次，每次在Git中進行操作時，都會添加新對象。 其中一些永遠不會永久保存。 這些（通常是松散的）對象是Git所謂的未引用對象：它們是為了保存它們而制成的，至少保存了一會兒甚至是永久性的，但是后來證明它們是不必要的，因此它們只是掉在地上了。

除此之外，每次重新確定提交的基准時，實際上都是在復制它們，然后放棄原始文檔。 但是Git默認情況下會將原件保留至少30天，以防萬一您改變主意並希望將其退回。 它使用Git的reflog來做到這一點。

這就是Git的“垃圾收集器” git gc出現的地方。垃圾收集器-Git的Grim Reaper或Grim Collector可能有很多工作，包括找出從reflog中淘汰的內容，應該拋出。 這可能會使更多的對象成為未引用的對象（除了創建的所有對象之外，然后最終證明它們是不需要的），因此它接下來查找未引用的松散對象並對其進行“修剪”。 最后，它可以將松散的對象打包為較小（但訪問速度較慢）的打包文件格式。

垃圾收集器會在需要時自動為您運行； 你不應該曾經有手動運行它。 如果您必須手動運行它，則表明Git中存在各種錯誤（我已經閱讀了一些這種情況，其中的腳本會使松散對象自動修剪過載）。 請注意，這通常會使未引用的松散對象保留至少14天，以防萬一仍在進行工作以使其成為引用。

[編輯以添加我應該在前面提到的最后兩項：]服務器通常在每次推送后運行git gc進行打包和清理； 並且有時會當場重新打包可下載版本，以使其盡可能小，或者至少盡可能小，“自動”（有時，您可以通過調整gc參數來使打包文件變得更小，盡管我第一次使用在Git上進行了實驗，我一直在使它們變大:-)）。