[[285646]]

 寫在前面

公司需要開發一個內部系統，要求每個部門都要接入。老板欽點，工期又壓得短，于是浩浩湯湯的上百人就調過來了。

再簡單的事情，只要人多起來就會變得復雜，開發的世界也是如此。

痛點

一個幾百人的大項目，使用Git協作的時候，想一想我們的痛點：

•  項目過大，每個人clone等待時間過長
•  一會沒有拉取代碼就會發現有上百條更新待拉取
•  一人提交出錯，上百人待機（筆者真實體驗）
•  代碼回溯困難，查找具體的修改記錄無異于大海撈針

解決方案

這時候Git子模塊就派上用場。

首先需要的當然是一個合理的架構，由于公司的保密原則這里就不貼項目了，本文主要描述在協作中子模塊的用法。

項目結構

項目主體結構大概是這樣的： 

└── src  
    ├── layout // 公共布局目錄  
    ├── public // 公共頁面目錄  
    ├── router // 路由入口  
    ├── components // 通用組件  
    ├── modules    // 模塊項目開發目錄（子模塊）  
    |    ├── tms    // 子模塊必須  
    |    │    ├── components // 模塊通用組件  
    |    │    ├── pages // 模塊頁面  
    |    │    ├── router // 模塊路由  
    |    │    └── store // 模塊vuex數據  
    |    └── ... // 各子模塊  
    ├── app.vue   // 跟組件  
    └──  main.js   // 項目入口 

一個部門一個子模塊，每個子模塊必須包含master（生產）、dev（開發）分支（推薦 gitflow 工作流）。

開發流程

克隆項目

如所有的webpack項目一樣，src只是業務代碼，開發配置都放在src外層，所以跑起開發環境首先需要克隆主項目。 

$ git clone https://github.com/test/main.git 

添加子模塊

當然我們一般不用master分支做開發，正確的姿勢是clone項目之后馬上切換到基于dev的開發分支（原則上業務組不需要關注主項目的開發，主項目由架構組負責，但是為了保證代碼的最新，并且將子模塊添加合并進dev分支中，所以切換到主分支dev）。 

$ git checkout -b dev origin/dev 

這時候如果你的項目中已經有子模塊了，你會發現modules文件夾下已經有了一個個子模塊，但是顯然現在這些模塊都是空目錄（預期的結果，我們不需要關注其他模塊）。同時項目根目錄下有一個.gitmodules文件，內容如下： 

[submodule "modules/suba"]  
    path = modules/suba  
    url = https://github.com/test/suba.git 

這里就是你的子模塊關聯文件，每添加一個子模塊就會新增一條記錄，如果是第一次添加Git子模塊會自動生成。

開發環境有了，現在需要關聯你的子模塊： 

$ git submodule add https://github.com/test/subb.git modules/subb 

首次添加的子模塊會拉取整個項目，打開muodules/subb文件夾，整個子模塊項目都完好地列在那里，同時.gitmodules里新增了一條子模塊記錄modules/subb。

編輯子模塊

同樣的，我們也不應該在子模塊的master分支上做任何編輯，這時候我們需要將子模塊切換到基于dev的開發分支。

進入子模塊目錄下： 

$ cd modules/subb/  
$ git checkout -b feature/some-change origin/dev 

當你在子模塊做完一些修改一些修改之后，你想要把這這些修改推送到遠程。 

$ git commit -am 'test commit submodule'  
$ git checkout dev  
$ git merge feature/some-change  
$ git push origin dev  
$ git branch -d feature/some-change 

這時候你的子模塊的修改就已經提交到遠程了，但是如果你進入到主項目的根目錄查看差異，你會發現主項目中多了一些修改： 

$ cd ../../  
$ git diff  
>   diff --git a/subb b/subb  
    index 433859c..b78179a 160000  
    --- a/subb  
    +++ b/subb  
    @@ -1 +1 @@  
    -Subproject commit 433859c90e539d2a1b9fda27b32bef0d0acae9e6  
    +Subproject commit b78179adab252a524ff2a41d6407a7daa6dad34f 

這是因為你修改了子模塊subb并提交了，但是主項目的指針依舊指向那個老的commit id，如果你不提交這個修改的話，別人拉取主項目并且使用git submodule update更新子模塊還是會拉取到你修改前的代碼。關于：Git 提交規范

所以這時候你需要把主項目也提交一遍： 

$ git commit -am "test commit submodule"  
$ git push origin dev 

這樣，你的修改就已經全部提交了。

新成員加入

當有新成員你加入你的子模塊并且需要拉取代碼的時候： 

$ git clone https://github.com/test/main.git  
$ git checkout -b dev origin/dev  
$ git submodule init  
$ git submodule update subb 

git submodule update [submodule name]是指定拉取指定子模塊的用法，如果你需要更新所有的子模塊只需要使用git submodule update就可以了，一般我們在協作中只關注自己的模塊。 

那么接下來新成員也可以延續我們上面的開發流程了。

刪除子模塊

當然也有需求變動或者添加錯誤的時候，這時候就需要刪除子模塊了，值得吐槽的是git沒有直接刪除子模塊的命令，所以只能逐步刪除相關文件：

在版本控制中刪除子模塊： 

$ git rm -r modules/subb 

在編輯器中刪除如下相關內容，也可以使用命令vi .gitmodules在vim中刪除： 

[submodule "modules/subb"]  
         path = modules/subb  
         url = https://github.com/test/subb.git  
         branch = dev 

在編輯器中刪除如下相關內容，也可以使用命令vi .git/config在vim中刪除： 

[submodule "modules/subb"]  
        url = https://github.com/test/subb.git  
        active = true 

刪除.git下的緩存模塊： 

$ rm -rf .git/modules/subb 

接下來提交修改： 

$ git commit -am "delete subb"  
$ git push origin dev 

發布項目

當整個開發流程都結束了，終于到了發布的時刻，當然需要在主項目更新你的所有子模塊： 

$ git checkout master  
$ git pull origin master  
$ git submodule update  
$ yarn build 

這時候就可以發布你整個項目了，關于協作中使用子模塊的操作就寫到這里，如果有疑問請在評論區留言。