Git submodule使用指南（二）

watcherlin發表於2019-04-10
Git

之前釋出了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分支上，那麼下一個進行子模組開發的人，就會包含到最新的程式碼

相關文章