目錄

1.背景

1.背景

背景章節參考:https://www.oschina.net/translate/how-to-handle-big-repositories-with-git?cmp

兩種大程式碼庫

實際工作中可能會遇到git大倉庫的場景。

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

1. 專案累積了非常長的歷史（專案成長了很長一段時間並且積累了包袱）。
2. 專案包括了巨大的二進位制資產，需要與程式碼一起跟蹤配對。
3. 兩者皆有。

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

將一個庫視為大規模庫的界線非常高 - 比如 Linux 核心的最後一個版本記錄了超過 1500 萬行程式碼，但人們仍然願意完整閱讀。

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

為了更快、更節省開發者和系統時間也更節約磁碟空間，第一個解決辦法是使用 git 進行淺克隆。通過淺克隆可以只克隆某個庫最後的歷史記錄。怎麼做到？只需要使用 --depth 選項，比如：

git clone --depth depth remote-url

想像一下，如果你的專案庫中積累了 10 年甚至更長時間的歷史記錄 - 比如 JIRA 是我們往 git 遷移的一個 11 年的老庫 - 累積節約的時間非常顯著。完整的克隆 JIRA 有 677 MB，如果包含工作目錄還有另外的 320+ MB，總共超過 47,000 多次提交。通過淺克隆的方式檢出 JIRE 需要 29.5 秒，而檢出完整的歷史記錄則需要 4 分 24 秒。隨著時間地推移及專案二進位制資產的增長，這個差距也會成比例的增長。任何情況下，構建系統都會大大受益於這種技術(指淺克隆)。

1.1.2另一個解決辦法是 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 來進行一次清理行動，應該警告你的團隊，計劃一個短期的凍結來進行操作，然後通知大家重新克隆庫。

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

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

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

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

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

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

git 在處理二進位制資產的時候並不是特別差勁，但它也不會幹得特別好。預設情況下，git 會完整壓縮儲存二進位制資產的所有後續版本，如果你有很多二進位制資產的情況下，這顯然不是最佳方案。

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

2.倉庫現狀

.

|-- icb1

|   |-- image

|   |   |-- bzImage

|   |   `-- icb1_zeos_linux_defconfig

|   `-- src

|       `-- linux-4.13.2

|           `-- linux-4.13.2_icb1.tar.gz

|-- imx8qm

|   |-- android-8.1

|   |   |-- image

|   |   |   |-- defconfig

|   |   |   |-- fsl-imx8qm-mek.dtb

|   |   |   `-- Image

|   |   `-- src

|   |       `-- kernel_imx_android.tar.gz

|   `-- linux-4.9.69

|       |-- image

|       |   |-- defconfig

|       |   |-- fsl-imx8qm-mek.dtb

|       |   `-- Image

|       `-- src

|           `-- kernel-imx8qm.tar.gz

`-- zcu102

    |-- image

    |   |-- defconfig

    |   |-- Image

    |   `-- zcu102_phy.dtb

    `-- src

        `-- linux-2017.3

            |-- linux-xlnx-2017.3_video_ea.tar.gz

            `-- system-top.dts

從目錄結構可以看出，我們資源庫中存在著大量的二進位制檔案，佔用空間已經達到十幾個G位元組，而且隨著專案的增加，倉庫必然更大，幾百個G，甚至上T。隨著專案的演進，資源庫中會存入其他資料，如文件、指令碼等輕量級檔案。如果為了看某些文件而將整個倉庫克隆下來，顯然是不划算的。

3.倉庫改造

目前倉庫所有二進位制程式碼都處於master分支。為了解決上面描述的問題，我們可以引入GIT的分支管理。

我們的構想是：輕量化master分支，對其他資源如文件、指令碼、原始碼、映象分別建立不同的分支來進行管理。Git 克隆時只克隆master分支，然後對需要的分支進行單獨處理。這樣，既節省了克隆時間，又節省了儲存空間。

下面，就對目前倉庫進行改造。

3.1第一步：先建立一個VM分支，並推送至伺服器

因為目前倉庫只有原始碼映象檔案，所以，只需要先把框架搭建起來；後面要增加文件、指令碼等就比較方便。

3.2第二步：輕量化master分支

目前採取的措施很暴力，直接清空master分支，讓其不儲存任何資源。這裡就會用到“背景”部分提到的核武器級選項“filter-branch”

--tree-filter 選項在檢出專案的每一個提交後執行指定的命令然後重新提交結果。在本例中，你從每一個快照中移除了一個叫作 passwords.txt 的檔案，無論它是否存在。

我們這裡可以使用：git filter-branch --tree-filter 'rm -rf *' HEAD命令，直接刪除所有。

3.3第三步：刪除倉庫目錄，重新克隆

因為，前面利用 filter-branch修改了整個倉庫的檔案及提交記錄，如前面“背景”部分提到的，你需要重新克隆工程，才能體驗到“.git資料夾”減小的快感。

這樣，架構已經搭建好了，如果後面要新增新的分支，就可以直接操作了。在新建分支時，預設會保留master的提交記錄，如果你不想這樣，可以用下面的命令：

--orphan引數可以讓你去掉歷史遺留提交記錄

4.倉庫使用

經歷了上面的倉庫改造後，如果新使用者的你直接克隆整個倉庫，仍然會將倉庫包含的所有分支資訊的.git資料夾下載下來。雖然其是壓縮後的資料檔案，但當二進位制檔案很多時，.git資料夾也會非常之大。

所以，我們可以只克隆倉庫的master分支下來（幾十KB），它包含了本地倉庫與遠端倉庫的聯絡。然後，再建立一個本地分支來跟蹤遠端你需要的分支。這樣，你就可以在本地只保留需要的分支的資料檔案。時間和空間都可以節省。命令示例入下：