git 是追蹤代碼庫(kù)演進(jìn)的***選擇 ，并且它能讓你與你的同事間高效協(xié)作。當(dāng)你想要追蹤的庫(kù)非常巨大時(shí)會(huì)發(fā)生什么？

在這篇文章里，我會(huì)嘗試著給你一些想法和技巧來(lái)恰當(dāng)?shù)靥幚聿煌N類的大倉(cāng)庫(kù)。

兩種大代碼庫(kù)

如果仔細(xì)想想，大概會(huì)有兩種導(dǎo)致倉(cāng)庫(kù)大規(guī)模增長(zhǎng)的原因：

• 項(xiàng)目累積了非常長(zhǎng)的歷史（項(xiàng)目成長(zhǎng)了很長(zhǎng)一段時(shí)間并且積累了包袱）。

• 項(xiàng)目包括了巨大的二進(jìn)制資產(chǎn)，需要與代碼一起跟蹤配對(duì)。

• 兩者皆有。

因此，倉(cāng)庫(kù)的增長(zhǎng)有兩個(gè)維度的方向：工作目錄的尺寸——例如：最近一次提交，和整個(gè)累積歷史的尺寸。

有時(shí)第二種問題會(huì)與老的過(guò)時(shí)的二進(jìn)制生成的東西（artifact）混合，它們都被放在倉(cāng)庫(kù)中，不過(guò)這類問題是比較容易處理的——如果它們很討厭，就覆蓋它們，見下文。

上述兩種場(chǎng)景需要的技巧和解決方案是不同的——盡管有時(shí)候需要互補(bǔ)——讓我們分別來(lái)處理它們吧。

處理?yè)碛写罅繗v史記錄的庫(kù)

將一個(gè)庫(kù)視為 大規(guī)模 庫(kù)的界線非常高 - 比如 Linux 內(nèi)核的***一個(gè)版本記錄了超過(guò) 1500 萬(wàn)行代碼，但人們?nèi)匀辉敢馔暾喿x - 由于監(jiān)管/規(guī)定方面的原因，某些很老的項(xiàng)目仍然需要保持完整，克隆它們是件痛苦的事情(現(xiàn)在通過(guò)拆分 Linux 庫(kù)的方式使其結(jié)構(gòu)清晰，它被拆分為歷史庫(kù)和最近時(shí)期的庫(kù)，需要通過(guò)嫁接設(shè)置來(lái)訪問完整的歷史記錄)。

淺克隆是簡(jiǎn)單的的解決辦法

為了更快、更節(jié)省開發(fā)者和系統(tǒng)時(shí)間也更節(jié)約磁盤空間，***個(gè)解決辦法是使用 git 進(jìn)行淺克隆。通過(guò)淺克隆可以只克隆某個(gè)庫(kù)***的歷史記錄。

怎么做到？只需要使用 --depth 選項(xiàng)，比如：

git clone --depth depth remote-url

想像一下，如果你的項(xiàng)目庫(kù)中積累了 10 年甚至更長(zhǎng)時(shí)間的歷史記錄 - 比如 JIRA 是我們往 git 遷移的一個(gè) 11 年的老庫(kù) - 累積節(jié)約的時(shí)間非常顯著。

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

最近 git 改善了對(duì)淺克隆的支持

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

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

巨大的庫(kù)往往存在著大量錯(cuò)誤的提交或無(wú)用的資源，對(duì)此，使用 filter-branch 是個(gè)很好的解決辦法。這個(gè)命令可以根據(jù)預(yù)先定義的模式對(duì)項(xiàng)目歷史進(jìn)行過(guò)濾、 整理 、修改，甚至跳過(guò)一些文件。它是 git 工具集中的一個(gè)非常強(qiáng)大的工具。目前已經(jīng)有腳本可以用于識(shí)別 git 庫(kù)中的大型對(duì)象，所以它使用起來(lái)非常容易。

使用 filter-branch 的示例：

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

filter-branch 有一個(gè)小小的缺點(diǎn)：一旦使用了 filter-branch，實(shí)際上已經(jīng)重寫了整個(gè)項(xiàng)目歷史，因此每次提交的 ID 都會(huì)發(fā)生變化。這要求每個(gè)開發(fā)者都要重新克隆更新后的庫(kù)。

所以，如果你打算使用 filter-branch 來(lái)進(jìn)行一次清理行動(dòng)，應(yīng)該警告你的團(tuán)隊(duì)，計(jì)劃一個(gè)短期的凍結(jié)來(lái)進(jìn)行操作，然后通知大家重新克隆庫(kù)。

淺克隆的替代者：只克隆一個(gè)分支

從 2012 年 4 月發(fā)布的 git 1.7.10 開始，你可以通過(guò)只克隆某一個(gè)分支來(lái)限制歷史記錄的數(shù)量，就像這樣：

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

對(duì)于長(zhǎng)期運(yùn)行分發(fā)的分支，或者你在有很多分支的情況下，這個(gè)特殊的技巧都非常有用。如果你只有極少數(shù)分支，那這個(gè)辦法不會(huì)帶來(lái)顯著的效果。

Stack Overflow 參考 。

處理?yè)碛芯薮蠖M(jìn)制資產(chǎn)的庫(kù)

第二類大型倉(cāng)庫(kù)中的代碼含有 巨大的二進(jìn)制資產(chǎn) 。游戲團(tuán)隊(duì)要處理巨大的 3D 模型，Web 開發(fā)團(tuán)隊(duì)需要跟蹤圖像資產(chǎn)，CAD 團(tuán)隊(duì)可能需要操作和跟蹤二進(jìn)制交付物的狀態(tài)。所以有各種不同的軟件團(tuán)隊(duì)在使用 git 的過(guò)程中會(huì)遇到這樣的問題。

git 在處理二進(jìn)制資產(chǎn)的時(shí)候并不是特別差勁，但它也不會(huì)干得特別好。默認(rèn)情況下，git 會(huì)完整壓縮存儲(chǔ)二進(jìn)制資產(chǎn)的所有后續(xù)版本，如果你有很多二進(jìn)制資產(chǎn)的情況下，這顯然不是***方案。

可以通過(guò)一些 基本的調(diào)整來(lái)改善情況 ，比如運(yùn)行垃圾回收 git gc，或者在 .gitattributes 中對(duì)部分二進(jìn)制類型進(jìn)行調(diào)整，以使用 delta 方式的提交。

不過(guò)有一點(diǎn)很重要，對(duì)項(xiàng)目中不同性質(zhì)的二進(jìn)制資產(chǎn)可能需要不同的方法。例如，這里需要檢查三個(gè)方面(感謝 Stefan Saasen 的評(píng)論)：

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

• 對(duì)于上述情形，就像某些文件通過(guò) zlib 壓縮并不會(huì)有多好的效果，你使用 core.compression 0 或 core.loosecompression 0 來(lái)關(guān)閉壓縮功能一樣；這是一個(gè)全局設(shè)置，它會(huì)對(duì)其它壓縮效果不錯(cuò)的非二進(jìn)制文件帶來(lái)負(fù)面影響。因此建議你把二進(jìn)制資產(chǎn)放在單獨(dú)的庫(kù)中。

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

• 探索調(diào)整 core.bigFileThreshold 帶來(lái)的效果。任何大于 512 MiB 都不會(huì)采用 delta 壓縮 - 如果沒有設(shè)置 .gitattributes 的話 - 所以這樣的調(diào)整值得一試。

技巧1: 稀疏檢出

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

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

• 僅克隆全部存儲(chǔ)庫(kù)一次：:git clone <repository-address>

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

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

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

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

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

技巧2：使用子模塊

還有另一種處理二進(jìn)制資產(chǎn)目錄的的方法，就是把它們拆分到一個(gè)單獨(dú)的庫(kù)，然后在主項(xiàng)目是通過(guò)把它拉取為 子模塊 。使用這種方法你可以控制資產(chǎn)的更新。需要了解子模塊，可以看看： 核心概念與技巧 和 另一個(gè)選擇 。

如果你想繼續(xù)使用子模塊的方法，你可能需要檢查 項(xiàng)目依賴 的復(fù)雜性。我提到的方法對(duì)解決大型二進(jìn)制文件問題會(huì)有所幫助。

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

git 中處理二進(jìn)制資產(chǎn)的第3個(gè)選擇依靠第三方擴(kuò)展。

我要說(shuō)的***個(gè)擴(kuò)展是 git-annex ，它可以使用 git 管理二進(jìn)制文件，但不需要把文件內(nèi)容檢入庫(kù)中。git-annex 使用一個(gè)特殊的鍵值庫(kù)來(lái)保存文件，然后將符號(hào)鏈接像普通文件一樣檢入 git 庫(kù)中進(jìn)行版本管理。這種用法非常直接，還有 一看就能明白的例子 。

第二個(gè)擴(kuò)展是 git-bigfiles ，一個(gè) git 分支， 適合于使用 git 分享項(xiàng)目大文件的人 。

不要因?yàn)槟愕膸?kù)有著巨大的歷史記錄或巨大的資產(chǎn)就放棄 git。這兩個(gè)問題都可以得到解決。