記一次 Git 管理經歷
摘要：
隨著負責的專案越來越大，出現了專人維護一個模組的可能，業務與模組劃分變得清晰可見，但出現瞭如下幾個問題：
Source 變的很重
模組版本管理變得不靈活
開發人員被迫接受很多不要關注的程式碼
以上問題，促使我尋找一種方案解決這個問題。先簡單介紹一下我們...
隨著負責的專案越來越大，出現了專人維護一個模組的可能，業務與模組劃分變得清晰可見，但出現瞭如下幾個問題：
- Source 變的很重
- 模組版本管理變得不靈活
- 開發人員被迫接受很多不要關注的程式碼
以上問題，促使我尋找一種方案解決這個問題。先簡單介紹一下我們的專案構成，由 DMP、DCP、DOP 三個主要業務模組構成，DCP 與其他兩個模組之間不存在任何直接關係，DOP 依賴了 DMP 提供的相應基礎服務包，DMP 也相對獨立，三個模組存在各自發版計劃，基於現狀，會採用統一的版本號進行管理，這顯然是不科學的，所以我提出了使用GIt Submodule
來解決這個問題。
|-docs |-apps |--dop |--ext |--toolkit |-sources |--basics |--components |--templates |--plugins |--terminals |-examples
DMP、DCP、DOP 三個業務模組分別建立一個 Git 進行維護。同時，例如：Basic
、Env
、Template
等公共模組都作為子模組進行管理。
DMP
|-docs |-apps |--dop(與DOP共用子模組) |--ext |--toolkit |-sources |--basics(與DOP共用子模組) |--components |--templates(與DOP共用子模組) |--terminals |-examples(子模組，許可權等級可以比較低，以供他人學習檢視)
DCP
|-docs |--toolkit |-sources |--components |--plugins |--terminals
DOP
|-docs |-apps(與DOP共用子模組) |-sources |--basics(與DMP共用子模組) |--components |--templates(與DMP共用子模組) |--terminals
看似好像模組變多了，但各個業務變得清晰，版本可控，公共部分進行Git Submodule
，使開發者只要關注需要關注的就行了，模組之間的許可權也變的靈活。
Git Submodule
使用
基於已有專案進行改造
Git Repository git push git submodule add
拓展
初始化 submodule 專案
git clone --recursive [遠端倉庫地址]
或者
git clone [遠端父倉庫地址] git submodule update --init --recursive git submodule foreach 'git checkout master; git pull'