git 是追蹤代碼庫演進的***選擇 ，并且它能讓你與你的同事間高效協作。當你想要追蹤的庫非常巨大時會發生什么？

在這篇文章里，我會嘗試著給你一些想法和技巧來恰當地處理不同種類的大倉庫。

兩種大代碼庫

如果仔細想想，大概會有兩種導致倉庫大規模增長的原因：

• 項目累積了非常長的歷史（項目成長了很長一段時間并且積累了包袱）。

• 項目包括了巨大的二進制資產，需要與代碼一起跟蹤配對。

• 兩者皆有。

因此，倉庫的增長有兩個維度的方向：工作目錄的尺寸——例如：最近一次提交，和整個累積歷史的尺寸。

有時第二種問題會與老的過時的二進制生成的東西（artifact）混合，它們都被放在倉庫中，不過這類問題是比較容易處理的——如果它們很討厭，就覆蓋它們，見下文。

上述兩種場景需要的技巧和解決方案是不同的——盡管有時候需要互補——讓我們分別來處理它們吧。

處理擁有大量歷史記錄的庫

將一個庫視為 大規模 庫的界線非常高 - 比如 Linux 內核的***一個版本記錄了超過 1500 萬行代碼，但人們仍然愿意完整閱讀 - 由于監管/規定方面的原因，某些很老的項目仍然需要保持完整，克隆它們是件痛苦的事情(現在通過拆分 Linux 庫的方式使其結構清晰，它被拆分為歷史庫和最近時期的庫，需要通過嫁接設置來訪問完整的歷史記錄)。

淺克隆是簡單的的解決辦法

為了更快、更節省開發者和系統時間也更節約磁盤空間，***個解決辦法是使用 git 進行淺克隆。通過淺克隆可以只克隆某個庫***的歷史記錄。

怎么做到？只需要使用 --depth 選項，比如：

git clone --depth depth remote-url

想像一下，如果你的項目庫中積累了 10 年甚至更長時間的歷史記錄 - 比如 JIRA 是我們往 git 遷移的一個 11 年的老庫 - 累積節約的時間非常顯著。

完整的克隆 JIRA 有 677 MB，如果包含工作目錄還有另外的 320+ MB，總共超過 47,000 多次提交。通過淺克隆的方式檢出 JIRE 需要 29.5 秒，而檢出完整的歷史記錄則需要 4 分 24 秒。隨著時間地推移及項目二進制資產的增長，這個差距也會成比例的增長。任何情況下，構建系統都會大大受益于這種技術(指淺克隆)。

最近 git 改善了對淺克隆的支持

過去淺克隆就像 git 世界里的殘障人士一樣，某些操作并未得到支持。不過最近的版本 (1.9+) 對此有著顯著的改善，現在甚至可以適當的對淺克隆庫使用 pull 和 push 操作。

另一個解決辦法是 filter-branch (過濾分支)

巨大的庫往往存在著大量錯誤的提交或無用的資源，對此，使用 filter-branch 是個很好的解決辦法。這個命令可以根據預先定義的模式對項目歷史進行過濾、 整理 、修改，甚至跳過一些文件。它是 git 工具集中的一個非常強大的工具。目前已經有腳本可以用于識別 git 庫中的大型對象，所以它使用起來非常容易。

使用 filter-branch 的示例：

git filter-branch --tree-filter 'rm -rf /path/to/spurious/asset/folder' HEAD

filter-branch 有一個小小的缺點：一旦使用了 filter-branch，實際上已經重寫了整個項目歷史，因此每次提交的 ID 都會發生變化。這要求每個開發者都要重新克隆更新后的庫。

所以，如果你打算使用 filter-branch 來進行一次清理行動，應該警告你的團隊，計劃一個短期的凍結來進行操作，然后通知大家重新克隆庫。

淺克隆的替代者：只克隆一個分支

從 2012 年 4 月發布的 git 1.7.10 開始，你可以通過只克隆某一個分支來限制歷史記錄的數量，就像這樣：

git clone URL --branch branch_name --single-branch [folder]

對于長期運行分發的分支，或者你在有很多分支的情況下，這個特殊的技巧都非常有用。如果你只有極少數分支，那這個辦法不會帶來顯著的效果。

Stack Overflow 參考 。

處理擁有巨大二進制資產的庫

第二類大型倉庫中的代碼含有 巨大的二進制資產 。游戲團隊要處理巨大的 3D 模型，Web 開發團隊需要跟蹤圖像資產，CAD 團隊可能需要操作和跟蹤二進制交付物的狀態。所以有各種不同的軟件團隊在使用 git 的過程中會遇到這樣的問題。

git 在處理二進制資產的時候并不是特別差勁，但它也不會干得特別好。默認情況下，git 會完整壓縮存儲二進制資產的所有后續版本，如果你有很多二進制資產的情況下，這顯然不是***方案。

可以通過一些 基本的調整來改善情況 ，比如運行垃圾回收 git gc，或者在 .gitattributes 中對部分二進制類型進行調整，以使用 delta 方式的提交。

不過有一點很重要，對項目中不同性質的二進制資產可能需要不同的方法。例如，這里需要檢查三個方面(感謝 Stefan Saasen 的評論)：

• 對于變化顯著的二進制文件 - 這是指不僅只有元數據頭變化 - 這時增量壓縮可能沒什么作用，建議對這些文件關閉 delta 選項，以避免不必要的增量壓縮并重新打包

• 對于上述情形，就像某些文件通過 zlib 壓縮并不會有多好的效果，你使用 core.compression 0 或 core.loosecompression 0 來關閉壓縮功能一樣；這是一個全局設置，它會對其它壓縮效果不錯的非二進制文件帶來負面影響。因此建議你把二進制資產放在單獨的庫中。

• 一定要記住 git gc 將“重復的”松散的對象變成一個單獨的包文件，除非以任何方式壓縮文件都不會使生成的包文件有顯著差異。

• 探索調整 core.bigFileThreshold 帶來的效果。任何大于 512 MiB 都不會采用 delta 壓縮 - 如果沒有設置 .gitattributes 的話 - 所以這樣的調整值得一試。

技巧1: 稀疏檢出

一個溫和的管理二進制資產問題的方法是 稀疏檢出 （從 Git 1.7.0 之后可用）。我們可以通過顯式地詳細說明要填充的文件夾來保持工作目錄的清潔。 不幸的是，它并不能影響整個本地存儲庫的大小，但如果你有一個巨大的樹形文件夾，這可能是有用的。

涉及到哪些命令呢？ 示例如下（ credit ）：

• 僅克隆全部存儲庫一次：:git clone <repository-address>

• 激活以下功能：git config core.sparsecheckout true

• 添加那些需要顯式依賴的文件夾，忽略 assets 文件夾：

echo src/ ? .git/info/sparse-checkout

• 讀取指定的樹目錄：git read-tree -m -u HEAD

之后，你可以使用正常的 git 命令了，但你的工作目錄將只包含你指定的文件夾。

技巧2：使用子模塊

還有另一種處理二進制資產目錄的的方法，就是把它們拆分到一個單獨的庫，然后在主項目是通過把它拉取為 子模塊 。使用這種方法你可以控制資產的更新。需要了解子模塊，可以看看： 核心概念與技巧 和 另一個選擇 。

如果你想繼續使用子模塊的方法，你可能需要檢查 項目依賴 的復雜性。我提到的方法對解決大型二進制文件問題會有所幫助。

技巧3：使用 git-annex 或 git-bigfiles

git 中處理二進制資產的第3個選擇依靠第三方擴展。

我要說的***個擴展是 git-annex ，它可以使用 git 管理二進制文件，但不需要把文件內容檢入庫中。git-annex 使用一個特殊的鍵值庫來保存文件，然后將符號鏈接像普通文件一樣檢入 git 庫中進行版本管理。這種用法非常直接，還有 一看就能明白的例子 。

第二個擴展是 git-bigfiles ，一個 git 分支， 適合于使用 git 分享項目大文件的人 。

不要因為你的庫有著巨大的歷史記錄或巨大的資產就放棄 git。這兩個問題都可以得到解決。