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

目前創(chuàng)新互聯(lián)公司已為上1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機、網(wǎng)站托管維護、企業(yè)網(wǎng)站設(shè)計、科爾沁右翼中網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

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

兩種大代碼庫

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

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

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

• 兩者皆有。

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

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

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

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

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

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

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

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

git clone --depth depth remote-url

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

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

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

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

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

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

使用 filter-branch 的示例：

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

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

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

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

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

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

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

Stack Overflow 參考 。

處理擁有巨大二進制資產(chǎn)的庫

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

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

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

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

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

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

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

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

技巧1: 稀疏檢出

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

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

• 僅克隆全部存儲庫一次：:git clone

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

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

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

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

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

技巧2：使用子模塊

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

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

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

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

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

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

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

網(wǎng)站標(biāo)題：Git如何處理大倉庫
文章位置：http://uogjgqi.cn/article/dpiccgs.html