Git submodule使用指南（二）

以前發佈了git submodule使用指南（一），今天這個第二篇，會寫一些修改方面的操做和個人理解。

我我的認爲，子模塊在使用的過程纔是最值得注意的地方，因此也沒有跟上面的內容一塊兒做爲「增刪改查」系列寫下去。 「改」 我認爲是最重要的一環。其中又能夠分爲：

1. 對本地的子模塊進行修改
2. 更新他人修改的子模塊內容

對本地的子模塊進行修改

上面提到更新子模塊的操做

git submodule update --remote
複製代碼

可是此時的子模塊是出於一個特殊的狀態，雖然上游的變化被更新到了本地，可是本地子模塊會處於一個遊離的HEAD狀態。

在HEAD狀態下，若是將本地修改的內容進行commit，是不會「附着」到任何分支上的。遊離的內容，會在切換分支以後消失。

那怎麼操做纔是正確的呢？

1. 先進入子模塊，而後檢出一個分支。
2. 再執行commit等本地操做
3. 執行git submodule update —remote —merge，將上游的變化合併到本地的這個分支上。若是你忘記—rebase或—merge，Git 會將子模塊更新爲服務器上的狀態。而且會將項目重置爲一個遊離的 HEAD 狀態。要彌補這個錯誤的話，從新執行1和3就能夠了。
4. 若是本地的文件跟上游文件出現衝突，則按照普通解決辦法解決了再提交就行了。
5. 發佈改動（推送）：在父倉庫執行git push時添加--recure-submodule 參數，此參數表示遞歸子模塊，能夠設置爲2個值「check」和「on-demand」。check會使沒推送子模塊的父倉庫自己推送失敗。而on-demand會嘗試自動推送子模塊後再推送父倉庫，若是子模塊因爲其餘緣由失敗，那麼父倉庫也會推送失敗。

合併子模塊的改動

根據Gitbook的描述，這是當同一分支在本地和上游出現了不一樣分叉，須要進行合併的時候，而且兩者不是祖先和後代的關係（或者說不是一條分子上的提交）。

操做方法以下：

1. 對上游的提交，進行檢出分支
2. 將1檢出的分支，合併到本地
3. 解決衝突
4. 回到主項目
5. 檢查子模塊的記錄
6. 解決子模塊衝突
7. 提交主倉庫合併

一些我我的的理解

子模塊的使用上面說得可能仍是有點比較繞，我我的認爲比較合適咱們團隊的子模塊工做流應該比較簡單。

1. 主項目須要在自模塊上開發新功能時，須要在主項目內的子模塊開新分支，而後進行開發
2. 子模塊的代碼須要獨立提交，造成commit信息記錄在主倉庫
3. 因爲主項目最終也是須要進行打包的，因此子模塊的版本只要是基於master，就認爲是可信的
4. 最後主項目的整個版本通過驗證須要上線後，則將子模塊的分支合併到子模塊的master分支上，那麼下一個進行子模塊開發的人，就會包含到最新的代碼