Alibaba Cloud DevOps：部分複製（Partial clone）介紹

什麼是部分複製?

眾所周知，Git是一個分布式的版本控制系統，當在預設情況（例如不帶任何參數情況下使用git clone命令）下複製倉庫時，Git會自動下載倉庫所有檔案的所有歷史版本。

如此設計一方面帶來了分布式的代碼協同能力, 但在另一方面, 隨著開發人員持續向倉庫中提交代碼，倉庫的體積會不可避免的變得越來越大, 因為遠端倉庫體積迅速膨脹, 帶來clone後本地後磁碟空間的迅速增長以及clone耗時的不斷增加。Git的部分複製（partial-clone）特性可以最佳化和解決這些問題。目前，部分複製已經在阿里雲Codeup上線, 使用者可以試用該功能體驗新特性帶來的研發效率的提升。

部分複製允許您在複製代碼倉庫時，通過添加--filter選項來配置需要過濾的對象，從而達到按需下載的目的，這種按需下載大大減少了傳輸的資料量和過程的耗時，同時還可以降低本地磁碟空間的佔用。在後續工作中需要用到這些缺失檔案的時候，Git會自動地按需下載這些檔案，在不必進行任何額外配置的情況下，使用者仍然可以正常開展工作。

部分複製的適用情境

在許多情境下，都可以用部分複製來提升您的效率，以幾個典型情境為例：

$ git clone --mirror gi*@codeup.aliyun.com:6125fa3a03f23adfbed12b8f/linux.git linux
複製到純倉庫 'linux'...
remote: Enumerating objects: 8345032, done.
remote: Counting objects: 100% (8345032/8345032), done.
remote: Total 8345032 (delta 6933809), reused 8345032 (delta 6933809), pack-reused 0
接收對象中: 100% (8345032/8345032), 3.26 GiB | 2.08 MiB/s, 完成.
處理 delta 中: 100% (6933809/6933809), 完成.

$ git clone --filter=blob:none  --no-checkout git@codeup.aliyun.com:6125fa3a03f23adfbed12b8f/linux.git
正複製到 'linux'...
remote: Enumerating objects: 6027574, done.
remote: Counting objects: 100% (6027574/6027574), done.
remote: Total 6027574 (delta 4841929), reused 6027574 (delta 4841929), pack-reused 0
接收對象中: 100% (6027574/6027574), 1.13 GiB | 2.71 MiB/s, 完成.
處理 delta 中: 100% (4841929/4841929), 完成.

monorepo
├── README
├── backend
│   └── command
│       └── command.go
├── docs
│   └── api_specification
├── frontend
│   ├── README.md
│   └── src
│       └── main.js
└── libraries
    └── common.lib

$ git clone --filter=blob:none  --no-checkout https://codeup.aliyun.com/61234c2d1bd96aa110f27b9c/monorepo.git
正複製到 'monorepo'...
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Total 24 (delta 0), reused 0 (delta 0), pack-reused 0
接收對象中: 100% (24/24), 2.62 KiB | 2.62 MiB/s, 完成.

$ cd monorepo
$ git config core.sparsecheckout true
$ echo "backend/*" > .git/info/sparse-checkout

$ tree .
.
└── backend
    └── command
        └── command.go

2 directories, 1 file

Git底層物件類型簡介

在使用部分複製前，還需要瞭解一些Git的底層儲存原理，以便更好地理解各個選項的含義，主要涉及blob對象，tree對象，以及commit對象。

下圖以Git底層對象的形式，展示了一個Git倉庫的結構。其中：

• 圓形，代表了commit對象，commit對象用於儲存提交資訊，並指向了父commit（如果存在）以及根tree對象。通過commit對象，我們可以回溯代碼的歷史版本。

• 三角形，代表一個tree對象，tree對象用於隱藏檔名及目錄結構資訊，並且指向blob對象或其他tree對象，由此組成嵌套的目錄結構。

• 方塊，代表了blob對象，儲存了檔案的實際內容。

部分複製使用限制

• 用戶端限制：本地的Git版本在2.22.0或更高。

• 服務端filter限制：目前，Codeup支援指定兩種--filter。

  • Blobless複製：--filter=blob:none。

  • Treeless複製：--filter=tree:<depth>。

在本地用戶端支援的情況下，就可以使用部分複製來提升研發效率了。

如何使用部分複製

要使用部分複製，有如下幾種方式：

• 使用 git clone 命令啟用部分複製：

  git clone --filter=blob:none <倉庫地址>

• 使用 git fetch 命令啟用部分複製

  git init .
  git remote add origin <倉庫地址>
  git fetch --filter=blob:none origin
  git switch master

• 使用 git config 設定倉庫啟用部分複製

  git init .
  git remote add origin <倉庫地址>
  git config remote.origin.promisor true
  git config remote.origin.partialclonefilter blob:none
  git fetch origin
  git switch master

這三種方式達到效果是一樣的，您可以自行選擇喜歡的方式。下面，我們用git clone的方式來分別介紹blobless複製和treeless複製的使用以及基本原理。

Blobless複製

在複製時使用--filter=blob:none選項，即可開啟blobless模式複製。在這種情況下，倉庫中歷史commit、tree會被下載，blob則不會。下面用一個例子來更好地說明使用此選項複製時倉庫的結構。

首先，建立一個測試倉庫。

• 在第一個提交中，建立檔案hello.txt，內容為hello world!。

• 在第二個提交中，建立檔案src/hello.go，內容為列印"hello world"。

• 在第三個提交中，修改檔案src/hello.go，修改輸出內容為“hello codeup"。

整個倉庫結構看起來像是這樣：

然後，執行以下命令，來執行一次blobless模式的部分複製

git clone --filter=blob:none \
https://codeup.aliyun.com/61234c2d1bd96aa110f27b9c/partial-clone-tutorial.git

複製完成後，進入此倉庫，並執行git rev-list命令來檢視倉庫中的對象，得到輸出為：

$ git rev-list --missing=print --objects HEAD
18990720b6e55a70ba9f9877213dad948e0973a2
e18cc4e7890e6ec832f683c1a0f58412b4a37964
2f7478bda13e73e1e1eaab6fae3d0dfd35e50b32
e7c719df0874ebd3b2ec02666d65879e986d537d
a0423896973644771497bdc03eb99d5281615b51 hello.txt
98a390b9c8b5ba25e9444c8b5a487634795d7c72 src
02a9d16faa87c68bd6fc2af27cbe3714e53af272 src/hello.go
b7458566de2bf5e1011142ef5fe81ccaa4c9e73e
3f2157b609fb05814ba0a45cf40a452640e663c3 src
6009101760644963fee389fc730acc4c437edc8f
?f2482c1f31b320e28f0dea5c4e7c8263a0df8fec

注意最後一行ID，第一個字元是問號，這也就意味著這個對象在本地其實是不存在的。為什麼會出現這種情況呢？其實這正是部分複製所要達到的效果。

下面來看看f2482c1f31b320e28f0dea5c4e7c8263a0df8fec這個對象是什麼，執行：

$ git cat-file -p f2482c1f31b320e28f0dea5c4e7c8263a0df8fec
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
接收對象中: 100% (1/1), 109 位元組 | 109.00 KiB/s, 完成.
package main
import "fmt"
func main() {
    fmt.Println("hello world")
}

第五行，接收對象意味著這個對象實際上是剛被下載下來的，其中內容為fmt.Println("hello world")，也就是第二個提交的版本。

通過以上分析，可以知道，使用部分複製blob:none選項複製倉庫後，只有第二個提交中的hello.go檔案不存在。

將圖形上色，空心代表對象不存在，實心代表對象存在，那麼倉庫結構可以表示成這個樣子：

可以看到，倉庫中歷史commit、tree對象都存在，歷史blob對象則不存在。把這個觀察推廣到更複雜一些的倉庫，就可以總結出以blobless模式複製倉庫的一般形式：

需要注意的是，在當前HEAD分支下，所有的tree和blob對象都存在，這是由於在複製之後自動執行了一次檢出。在此基礎之上，可以修改，提交代碼，展開工作。對於歷史提交來說，commit和tree對象都存在，僅有blob對象未被下載。通過不下載這些歷史blob對象，達到了節省複製時間，節省磁碟佔用空間的目的。

如果此時檢出歷史提交，那麼Git用戶端會自動地批量下載這些缺失的blob對象。此外，當需要使用到檔案內容時，就會觸發blob下載，當只需要檔案的OID時，就不需要了。這也就意味著可以運行git merge-base、git log等命令，效能與完全複製模式相同。

Treeless複製

在複製時使用--filter=tree:<depth>選項，就開啟了無tree複製，其中depth是一個數字，代表了從commit對象開始的深度。在這種模式下，只有給定深度內的tree以及blob對象會被下載。

回到測試倉庫，這次利用--filter=tree:0來啟用treeless複製，並用rev-list來檢視本機物件：

$ git clone --filter=tree:0 \
https://codeup.aliyun.com/61234c2d1bd96aa110f27b9c/partial-clone-tutorial.git
$ cd partial-clone-tutorial

$ git rev-list --missing=print --objects HEAD
18990720b6e55a70ba9f9877213dad948e0973a2
e18cc4e7890e6ec832f683c1a0f58412b4a37964
2f7478bda13e73e1e1eaab6fae3d0dfd35e50b32
e7c719df0874ebd3b2ec02666d65879e986d537d
a0423896973644771497bdc03eb99d5281615b51 hello.txt
98a390b9c8b5ba25e9444c8b5a487634795d7c72 src
02a9d16faa87c68bd6fc2af27cbe3714e53af272 src/hello.go
?b7458566de2bf5e1011142ef5fe81ccaa4c9e73e
?6009101760644963fee389fc730acc4c437edc8f

現在問號出現在兩個對象ID前，來看看這些對象是什麼：

$ git cat-file -p HEAD^^
tree 6009101760644963fee389fc730acc4c437edc8f
author yunhuai.xzy <yunhuai.***@alibaba-inc.com> 1631697940 +0800
committer yunhuai.xzy <yunhuai.***@alibaba-inc.com> 1631697940 +0800

first commit

$ git cat-file -p HEAD^
tree b7458566de2bf5e1011142ef5fe81ccaa4c9e73e
parent 2f7478bda13e73e1e1eaab6fae3d0dfd35e50b32
author yunhuai.xzy <yunhuai.***@alibaba-inc.com> 1631698032 +0800
committer yunhuai.xzy <yunhuai.***@alibaba-inc.com> 1631698032 +0800

add hello.go

注意其中第二行，可以發現b74585和b74585這兩個對象，正好是第一第二個提交所指向的根樹。畫出倉庫結構如下：

推廣到更一般的Git倉庫，則如下圖所示：

可以看到，擁有所有提交資訊，以及在HEAD分支下的所有對象（還是由於自動檢出），但不包含任何歷史提交中的tree和blob。

與blobless模式相比，treeless模式需要下載的對象更少了，複製時間會更短，磁碟佔用空間也會更少。但是在後續工作中，treeless模式的複製會更加頻繁的觸發資料的下載，並且代價也更為昂貴。例如，Git用戶端會向服務端請求一顆樹及其所有的子樹，在這個過程中，用戶端不會告訴服務端本地已有一些樹，服務端不得不把所有的樹都發送給用戶端，然後用戶端可以對缺失的blob對象發起批量請求。

為了更好理解treeless複製，下圖是一個使用了--filter=tree:1選項的例子。可以看到，深度為1的tree對象也被下載了，更深的tree或者blob對象則沒有。

在日常開發過程中，不建議使用treeless模式的複製，treeless複製更加適用於自動構建的情境，快速的複製倉庫，構建，然後刪除。

部分複製的其他選項

部分複製還可以使用其他選項，完整選項請參考https://git-scm.com/docs/git-rev-list中的--filter=<filter-spec>節，正在逐步支援其他選項。

Git LFS（大檔案儲存體）

除了部分複製，Codeup 同時提供 Git LFS 大檔案儲存體能力。關於Git LFS，請參考Git-LFS 大檔案儲存體。

部分複製與Git LFS的異同

部分複製與大檔案儲存體也不是割裂的，可以結合使用，以達到更好的代碼協同體驗。例如，使用部分複製來減少歷史對象的下載，同時使用Git LFS來管理大檔案。Codeup對這兩個特性都進行了支援，您可以根據實際情況合理選擇和結合使用部分複製和Git LFS，以有效最佳化大型倉庫的管理和使用體驗。