1、背景與難點(diǎn)

目前，前端平臺(tái)探索大倉研發(fā)模式，通過Monorepo大倉的技術(shù)，整合前端平臺(tái)現(xiàn)有應(yīng)用的倉庫代碼，使得各業(yè)務(wù)域應(yīng)用質(zhì)量衡量標(biāo)準(zhǔn)統(tǒng)一，通用基礎(chǔ)組件以及工具函數(shù)能夠快速復(fù)用，當(dāng)基礎(chǔ)通用功能出現(xiàn)問題的時(shí)候，能快速地在各應(yīng)用中升級(jí)，提升研發(fā)工作效率，節(jié)省人效。

我們知道在普通的項(xiàng)目開發(fā)中進(jìn)行 git 的克隆和拉取不會(huì)遇到什么問題。但是隨著我們代碼的不斷擴(kuò)充，代碼倉庫內(nèi)容會(huì)變得越來越大，需要幾個(gè)G甚至幾十上百G的磁盤空間時(shí)，如果把所有代碼都pull到本地屬實(shí)是個(gè)不現(xiàn)實(shí)的方式，不僅是我們沒有這么大的磁盤空間，而且還有網(wǎng)絡(luò)流量的占用問題以及網(wǎng)絡(luò)速度問題都是沒有辦法解決。而且，如果Git倉庫特別大，每次執(zhí)行Git命令，等待時(shí)間會(huì)特別長。對(duì)于這些問題，我們做了相關(guān)的技術(shù)調(diào)研。

2、技術(shù)調(diào)研

我們調(diào)研了下Facebook和Google大倉代碼按需拉取的實(shí)現(xiàn)，其使用方式大致如下：

Facebook

mercurial：是一個(gè)分布式版本控制工具(類似Git，是Matt Mackall開發(fā))，采用的是基于內(nèi)容尋址的技術(shù)。當(dāng)對(duì)一個(gè)文件進(jìn)行修改時(shí)，mercurial 不會(huì)直接修改文件本身，而是創(chuàng)建一個(gè)新版本，該版本包括指向之前版本的引用以及所做修改的差異。這樣，就可以在沒有改變之前版本的基礎(chǔ)上構(gòu)建新版本，同時(shí)正確地跟蹤文件的變化歷史。

Vscode工具：支持下載局部代碼 & 全局代碼檢索等能力

• Google
• Piper：代碼管理系統(tǒng)(類似github)，是一個(gè)強(qiáng)大的分布式版本控制和數(shù)據(jù)管理系統(tǒng)，它使用了 Google 自行開發(fā)的 Colossus 文件系統(tǒng)、索引機(jī)制等多項(xiàng)技術(shù)來實(shí)現(xiàn)高效的管理和處理大規(guī)模的代碼庫，并具有高可擴(kuò)展性、高可靠性和高吞吐量等特點(diǎn)。
• Citc: 云存儲(chǔ)客戶端，用來和piper進(jìn)行交互

像Facebook和Google都是自研的類似Git的工具，如果我們自己自研的話，成本會(huì)很大。所以，目前是另辟蹊徑選擇了基于 git 的sparse checkout 來實(shí)現(xiàn)。Git在2.25及以上版本提供了sparse checkout的能力，能夠?qū)崿F(xiàn)代碼的按需拉取。

3、實(shí)現(xiàn)原理

3.1 git sparse checkout的原理

3.1.1 sparse checkout定義

所謂稀疏檢出就是，Git本地庫檢出時(shí)不檢出全部，只將指定的文件從Git本地庫檢出到Git工作區(qū)，而其他未指定的文件則不予檢出（即使這些文件存在于工作區(qū)，其修改也會(huì)被忽略）。

3.1.2 sparse checkout原理

當(dāng)開啟sparse checkout功能的時(shí)候， Git 從遠(yuǎn)程倉庫下載整個(gè)倉庫對(duì)象的元數(shù)據(jù)（metadata），而不是下載所有的文件。具體來說，Git下載倉庫時(shí)，首先下載倉庫的基礎(chǔ)元數(shù)據(jù)對(duì)象（如提交對(duì)象、樹和blob等），然后將基礎(chǔ)數(shù)據(jù)對(duì)象整合成commit對(duì)象，并下載相關(guān)的歷史記錄。在這個(gè)過程中，Git會(huì)逐步下載和存儲(chǔ)文件的有關(guān)信息（例如文件名、大小和內(nèi)容哈希值），但并不會(huì)立即下載所有文件的內(nèi)容。只有當(dāng)執(zhí)行檢出命令時(shí)，Git才會(huì)根據(jù)指定的分支或標(biāo)簽，從遠(yuǎn)程倉庫下載所需的文件的實(shí)際內(nèi)容。

Git 實(shí)現(xiàn)這個(gè)稀疏檢出，是靠一個(gè)skip-worktree的標(biāo)識(shí)， 即在 index (即Git暫存區(qū))中為每個(gè)文件提供一個(gè)名為 skip-worktree 的標(biāo)志位，默認(rèn)這個(gè)標(biāo)志位處于關(guān)閉狀態(tài)。如果開啟該標(biāo)志位，則無論Git工作區(qū)對(duì)應(yīng)的文件存在是否，或者是否被修改，Git都認(rèn)為Git工作區(qū)該文件的版本是最新的、無變化的。Git通過配置文件 .git/info/spare-checkout 定義一個(gè)要檢查的目錄和或文件列表，當(dāng)前Git的基于合并（git merge、git checkout）等命令能夠根據(jù)該配置文件更新的index中文件的 skip-worktree 表示位，實(shí)現(xiàn)Git本地庫文件的稀疏檢出。

• 執(zhí)行 "git checkout" 命令來檢出僅僅包含所選目錄或文件路徑的副本倉庫，不包括篩選掉的文件或目錄。
• 當(dāng)執(zhí)行 "git add" 命令時(shí)，會(huì)根據(jù) sparse-checkout 文件進(jìn)行文件過濾，只有匹配到正則表達(dá)式描述的文件才會(huì)被加入到 Git 的跟蹤列表中。

3.2 基于sparse checkout的CLI實(shí)現(xiàn)

我們先來看下在 git 中手動(dòng)使用sparse checkout 操作的一般步驟 ：

第一步，git 初始化
git init


第二步，設(shè)置remote倉庫地址
git remote add orgin git@pkg.xxx.com:du-monorepo/XXXXX.git


第三步，初始化
git sparse-checkout init —cone


第四步，添加目錄
git sparse-checkout add xxx/xx ...


第五步，檢出
git pull orgin master

為了更方便地使用 sparse checkout 特性，我們開發(fā)了命令行工具，集合封裝了按需檢出相關(guān)的操作步驟。

3.2.1 cli 操作步驟

1. 命令行執(zhí)行 dx init
2. 選擇業(yè)務(wù)域
3. 選擇項(xiàng)目
4. 檢出目標(biāo)項(xiàng)目

這里面所做的就是把稀疏檢出的操作流程集合在了統(tǒng)一的命令行里面了，便于操作。本質(zhì)上還是差不多上文demo里面所描述的內(nèi)容。

圖片

上圖是前端大倉目前已經(jīng)遷移的全部應(yīng)用目錄結(jié)構(gòu)，可以看到不同的業(yè)務(wù)域下有不同的應(yīng)用，比如客服的研發(fā)只關(guān)注客服的應(yīng)用，商家的研發(fā)只關(guān)注商家的應(yīng)用，通過上面的CLI操作步驟只需拉取對(duì)應(yīng)目錄下的代碼就可以了，流程效果如下：

3.2.2 實(shí)現(xiàn)流程

圖片

如上圖所示，整個(gè)cli 是基于Pipline 的設(shè)計(jì)模式，Pipeline模式為管道模式，也稱為流水線模式。通過預(yù)先設(shè)定好的一系列的階段來處理輸入的數(shù)據(jù)，每個(gè)階段的輸出即是下一個(gè)階段的輸入(Pipeline其實(shí)是使用了責(zé)任鏈模式的思想)。模型圖如下：

圖片

Pipeline設(shè)計(jì)模式的精髓在于它的可配置化，并且嵌套可拓展。在使用Pipeline時(shí)，如果想調(diào)換Valve的順序，或者某些業(yè)務(wù)是不是用某個(gè)Valve，都是可以在外部配置的。這樣就可以很靈活地適配多樣化的業(yè)務(wù)，針對(duì)不同的業(yè)務(wù)配置不同的處理流程，擴(kuò)展性、靈活性比較強(qiáng)。

3.3 基于sparse checkout的VSCode插件實(shí)現(xiàn)

3.3.1 大倉VsCode插件組成要素

大倉VsCode插件由【啟動(dòng)按鈕】、主側(cè)邊欄【HELP】以及【Monorepo管理面板】三個(gè)要素組成

插件組成要素

3.3.2 插件實(shí)現(xiàn)原理

下面介紹下這三個(gè)元素以及元素間聯(lián)動(dòng)的代碼實(shí)現(xiàn)。

• 插件代碼結(jié)構(gòu)&基本架構(gòu)

代碼結(jié)構(gòu)

插件基本架構(gòu)

• 插件啟動(dòng)按鈕

啟動(dòng)按鈕是在package.json里配置的，配置項(xiàng)為contributes.viewsContainers.viewsContainers，可以配置按鈕的id，標(biāo)題和icon

圖片

當(dāng)點(diǎn)擊啟動(dòng)按鈕后，就會(huì)激活插件，并執(zhí)行activate的鉤子函數(shù)，activate需要在名為extension.ts的文件中實(shí)現(xiàn)并導(dǎo)出：

圖片

當(dāng)插件被銷毀時(shí)，會(huì)調(diào)用extension.ts導(dǎo)出的deactivate鉤子函數(shù)，在這個(gè)鉤子里可以進(jìn)行一些資源的銷毀。

其中activate執(zhí)行了打開【Monorepo管理面板】的代碼，這樣插件在啟動(dòng)時(shí)就會(huì)自動(dòng)打開面板。

• 主側(cè)邊欄【HELP】

該元素也是在package.json中配置的，配置項(xiàng)為：contributes.viewsWelcome，可以在content配置項(xiàng)中配置內(nèi)容，綁定視圖，并為按鈕的點(diǎn)擊事件綁定響應(yīng)指令，這里綁定的指令是自定義指令：monorepo-init-extend.startClone。

圖片

在extension.ts中注冊(cè)自定義指令：monorepo-init-extend.startClone，以及執(zhí)行該指令的響應(yīng)。

圖片

可以看到該指令將創(chuàng)建并打開【Monorepo管理面板】，從而實(shí)現(xiàn)主側(cè)邊欄【HELP】和【Monorepo管理面板】之間的聯(lián)動(dòng)效果。當(dāng)用戶點(diǎn)擊【HELP】中的【請(qǐng)選擇應(yīng)用】時(shí)，就會(huì)執(zhí)行該指令并打開【Monorepo管理面板】。

• Monorepo管理面板

Monorepo管理面板是通過在VSCode中創(chuàng)建一個(gè)webviewPanel，并注入html模版來實(shí)現(xiàn)的。并且插件和webview之間可以通過postMessage api來進(jìn)行通信。如在【Monorepo管理面板】中，當(dāng)點(diǎn)擊了【確定】按鈕，就會(huì)通過postMessage將所選應(yīng)用的信息通過postMessage發(fā)送給插件，插件將這些信息作為執(zhí)行初始化或代碼追加指令的參數(shù)，借助稀疏檢出的命令行工具，執(zhí)行相應(yīng)的指令，即可按需拉取代碼到本地。在插件執(zhí)行完指令后，就會(huì)將相應(yīng)的反饋信息通過postMessage發(fā)送給【Monorepo管理面板】。

Monorepo管理面板中樹形結(jié)構(gòu)的應(yīng)用列表數(shù)據(jù)是通過前端統(tǒng)一配置中心獲取的，支持動(dòng)態(tài)可配置：

圖片

4、技術(shù)挑戰(zhàn)

基于Git的代碼按需拉取雖然實(shí)現(xiàn)了，但是基于Git的文件系統(tǒng)是存在弊端的：

• Git 文件系統(tǒng)中的每個(gè)版本都是一組完整的快照，因此在執(zhí)行稀疏操作時(shí)，用戶需要指定需要的文件或目錄，此時(shí) Git 會(huì)進(jìn)行文件或目錄的部分檢出。但是，由于 Git 文件系統(tǒng)中的快照是完整的，因此即使只檢出部分文件或目錄，Git 仍需要讀取不相關(guān)的文件或目錄，導(dǎo)致 I/O 操作和網(wǎng)絡(luò)傳輸量增加，尤其對(duì)于大型代碼庫來說，這會(huì)增加服務(wù)器和網(wǎng)絡(luò)的負(fù)擔(dān)。

Git 仍需要讀取不相關(guān)的文件或目錄：這是因?yàn)?Git 文件系統(tǒng)使用的是內(nèi)容尋址（content-addressable）的存儲(chǔ)方式，即每個(gè)對(duì)象的名稱都是由其內(nèi)容（也就是文件的具體內(nèi)容）計(jì)算出的 SHA-1 校驗(yàn)和。每個(gè)提交（commit）都是一個(gè)完整的目錄樹（tree）對(duì)象，其中包含了所有的文件和子目錄。由此，在執(zhí)行稀疏檢出時(shí)，Git 需要讀取整個(gè)目錄樹（包括不相關(guān)的文件和目錄）以計(jì)算出其 SHA-1 校驗(yàn)和和對(duì)象名，然后根據(jù)用戶的請(qǐng)求將需要的文件和目錄進(jìn)行檢出。

• Git 文件系統(tǒng)中的歷史記錄是由一系列提交組成的，每個(gè)提交最多保存一個(gè)完整的快照。因此，如果對(duì)代碼庫進(jìn)行了稀疏檢出，從歷史記錄中檢查或恢復(fù)文件或目錄可能會(huì)變得更加困難，因?yàn)闅v史記錄只能訪問和操作現(xiàn)在存在的文件或目錄，而不包括被檢出的、或不再在代碼庫中的文件或目錄。

由于 Git 文件系統(tǒng)是基于快照（snapshot）記錄歷史記錄的，每個(gè)提交都包含整個(gè)代碼庫的目錄樹對(duì)象和其中所有文件的快照，那么如果使用稀疏檢出機(jī)制來指定只檢出部分文件或者目錄，那么在檢查或恢復(fù)歷史版本的時(shí)候，只能訪問和操作現(xiàn)在存在的文件或目錄。因?yàn)槟切┲氨缓Y選過去的文件或目錄現(xiàn)在不在當(dāng)前檢出的代碼庫中，所以無法直接訪問它們的歷史版本。

• sparse checkout是基于Git的元數(shù)據(jù)實(shí)現(xiàn)的，跟Git文件系統(tǒng)天然綁定。如果當(dāng)代碼量達(dá)到一定體量的時(shí)候，Git的元數(shù)據(jù)會(huì)非常龐大，特別是后續(xù)試行主干開發(fā)分支的時(shí)候，元數(shù)據(jù)會(huì)膨脹的很快，當(dāng)達(dá)到Git本身性能臨界點(diǎn)的時(shí)候，就會(huì)出現(xiàn)git相關(guān)操作卡頓的情況，如git add、git commit等相關(guān)命令執(zhí)行會(huì)非常緩慢。所以維護(hù)好Git的元數(shù)據(jù)在一定的范圍內(nèi)非常重要，這也是我們后續(xù)在分支維護(hù)策略上比較大的技術(shù)挑戰(zhàn)。

5、總結(jié)

本文主要對(duì)于git sparse checkout 的原理和在其之上的應(yīng)用——大倉按需拉取cli和 vscode按需拉取插件展開講解，實(shí)現(xiàn)了初版的基礎(chǔ)能力，當(dāng)然不可避免也存在著一些問題，當(dāng)下的按需檢出實(shí)現(xiàn)方案可能不是最終極的解決辦法，但它卻是最適合我們當(dāng)下業(yè)務(wù)進(jìn)程的方案。后面還會(huì)繼續(xù)迭代和優(yōu)化，同時(shí)關(guān)注git官方能力的改善以及我們自身對(duì)未來滿足需求能力上的前置探索。