若是項目分的模塊比較多,並且對每一個模塊須要獨立管理的話,子模塊就派上用場了。每個子模塊都是一個獨立的git倉庫,有點相似於svn的外鏈。下面簡單講一下在現有的git倉庫裏添加子模塊的配置。git
在主項目中添加子模塊程序員
git submodule add git@gitlab.code.anzogame.com:octopus/L1.git
這就完啦?對,就這麼簡單,回車後就會自動clone子模塊的最新代碼下來,並命名爲L1,固然也能夠重命名,只須要在命令後面跟上須要重命名的名字便可。svn
clone帶子模塊的項目,前提是對子模塊的倉庫是有相應權限的gitlab
//方式一 git clone --recursive <url> //方式二 git clone <url> git submodule init git submodule update
其實主項目只是保存了一個子模塊的地址和對應的commit號,以下圖:url
**注意這裏只指向子模塊倉庫的某一個版本,通常狀況下並不會特別指向某一個分支,clone
代碼的時候是把這個版本的代碼clone
下來了(不必定的子模塊最新的代碼)。**以下圖:指針
不在分支上的本地工做區是不能提交同步代碼的,因此這裏若是後續須要對子模塊修改提交併同步的話,是須要手動切換都某一個分支的,以下圖:code
對子模塊內容作修改後的提交同步
注意看紅色L1後面的狀態,
untracked content
的意思是L1子模塊裏有內容修改,而且這個修改並無被加入版本管理裏。it
commit
,主項目裏的子模塊的commit
號就會隨之改變,再看一下狀態: 此時L1後面跟的是
new commits
,這表明主項目所保存的子模塊的版本號已經改變了,你須要將這個版本號在主項目也提交才行,否則就會出現不匹配的狀態。版本管理
cd
進入子模塊進行push
,同步真正修改的內容到遠程倉庫,而後再回到主項目push
,就是同步推送主項目指向子模塊的commit
號到遠程倉庫。這裏有個坑,你們剛開始的時候會常常遇到。甲同窗
對L1子模塊進行了修改而且同步到遠程倉庫了,可是沒有提交主項目對這個子模塊的版本號,這時乙同窗
對子模塊L1進行了單獨的更新,這個時候問題就出現了,乙同窗
在主項目git status
查看狀態的時候會出現L1是紅色的,而且是[new commits]狀態,**這是由於乙同窗
主項目裏L1子模塊的版本號已經變了,子模塊的版本號只由當前子模塊的最新commit號決定,也就是HEAD指針指向的commit號。**因此這個時候須要請甲同窗
提交一下,若是不提交問題也不大,乙同窗
本身提交上去,只是這個時候甲同窗
再提交會出現L1的這commit號衝突,由於對於主項目來講這個子模塊版本號兩我的都作了修改,可是這個能夠不解決,由於這個commit號是手動改不了了,也就是說不用解決這個衝突,保持最新就好。可是衝突老是你們不想遇到的,因此在對子模塊有修改的時候儘可能都把對應的主項目的版本號也提交上去,這纔是最正確的操做。
多個子模塊簡便操做
當遇到一個功能須要多個子模塊都同時作了修改,那麼相應的對這幾個子模塊都要作一次提交,這個時候若是一個一個的cd進去再提交同步就會是個很是麻煩的事情,程序員都是懶得。這個時候用下面這個命令就能夠完美解決:
git submodule foreach "<git command>"
他會對子模塊一個一個的執行尖括號裏的命令,例如git submodule foreach "git push"
講完了!