之前釋出了git submodule使用指南（一），今天這個第二篇，會寫一些修改方面的操作和我的理解。
我個人認為，子模組在使用的過程才是最值得注意的地方，所以也沒有跟上面的內容一起作為“增刪改查”系列寫下去。 “改” 我認為是最重要的一環。其中又可以分為：
- 對本地的子模組進行修改
- 更新他人修改的子模組內容
對本地的子模組進行修改
上面提到更新子模組的操作
git submodule update --remote
複製程式碼但是此時的子模組是出於一個特殊的狀態，雖然上游的變化被更新到了本地，但是本地子模組會處於一個遊離的HEAD狀態。
在HEAD狀態下，如果將本地修改的內容進行commit，是不會“附著”到任何分支上的。遊離的內容，會在切換分支之後消失。
那怎麼操作才是正確的呢？
- 先進入子模組，然後檢出一個分支。
- 再執行commit等本地操作
- 執行
git submodule update —remote —merge，將上游的變化合併到本地的這個分支上。如果你忘記—rebase或—merge，Git 會將子模組更新為伺服器上的狀態。並且會將專案重置為一個遊離的 HEAD 狀態。要彌補這個錯誤的話，重新執行1和3就可以了。 - 如果本地的檔案跟上游檔案出現衝突，則按照普通解決辦法解決了再提交就好了。
- 釋出改動（推送）：在父倉庫執行
git push時新增--recure-submodule引數，此參數列示遞迴子模組，可以設定為2個值“check”和“on-demand”。check會使沒推送子模組的父倉庫本身推送失敗。而on-demand會嘗試自動推送子模組後再推送父倉庫，如果子模組由於其他原因失敗，那麼父倉庫也會推送失敗。
合併子模組的改動
根據Gitbook的描述，這是當同一分支在本地和上游出現了不同分叉，需要進行合併的時候，並且二者不是祖先和後代的關係（或者說不是一條分子上的提交）。
操作方法如下：
- 對上游的提交，進行檢出分支
- 將1檢出的分支，合併到本地
- 解決衝突
- 回到主專案
- 檢查子模組的記錄
- 解決子模組衝突
- 提交主倉庫合併
一些我個人的理解
子模組的使用上面說得可能還是有點比較繞，我個人認為比較合適我們團隊的子模組工作流應該比較簡單。
- 主專案需要在自模組上開發新功能時，需要在主專案內的子模組開新分支，然後進行開發
- 子模組的程式碼需要獨立提交，形成commit資訊記錄在主倉庫
- 由於主專案最終也是需要進行打包的，所以子模組的版本只要是基於master，就認為是可信的
- 最後主專案的整個版本經過驗證需要上線後，則將子模組的分支合併到子模組的master分支上，那麼下一個進行子模組開發的人，就會包含到最新的程式碼