Git 分支策略與submodule對分支策略的影響

當前的分支策略：

1. 在master上進行主要的功能開發，功能開發完成後修改完大部分bug之後，從當前master分支上切出preRelease分支；
2. 在preRelease上繼續修改bug，在master分支上開始做新需求，這兩個是並行的；
3. 在preRelease修改bug完成之後，釋出到市場，然後將preRelease分支合併到Release分支和master分支，刪除preRelease分支；

引入submodule出現的問題：

• Release 分支的目的是為了防範線上版本出現問題，能夠迅速找到對應節點的程式碼，修復bug，重新上線緊急版本。但是實際操作可能會出現一個問題，我們拉取了線上版本對應節點的程式碼，但是與submodule相關的部分卻報錯，因為submodule也在不停地修改中，而線上版本節點對應的submodule節點（包括branch和commit點)，我們並不知道。

如何解決這個問題：

• 使用cocoapods管理submodule，submodule如果有修改，要即使修改podspec的版本號，並且在主專案的podfile中要規定好正確的submodule版本號；這種方法能很好的管理版本之間的依賴關係，但是如果對於submodule需要頻繁更新的情況，效率是不太高，而且略繁瑣。
• 手動記錄對應線上版本節點對應的submodule的節點；這個方法有點傻，但實施起來是最簡便的。
• 其他方案

為什麼之前修改過的問題後面還是會出現/為什麼merge程式碼可能也需要多人一起並且很久：

1. 這個問題可能是出在 “preRelease分支合併到master分支”這個步驟上；
2. preRelease和master是並行開發，合併的時候，主專案的程式碼和submodule的程式碼都可能不一樣了；假如有一個submodule是藍芽模組，在preRelase分支上修改bug時對藍芽模組做了修改，在master分支上適配新的藍芽協議也對藍芽模組做了修改，而主專案上的程式碼很多也都依賴了藍芽模組，所以也會有很多不同（我們先不考慮主專案上其他需求的新程式碼和修改bug的新程式碼）。這個時候，如何做合併？誰來做合併？怎麼做取捨？要花費多少時間？如果在時間快和程式碼穩健上選一個，選哪個？
3. 很多時候，我們是選擇節省時間（雖然最終是否真的節約了時間先不說，但肯定是節約了merge程式碼的時間）。出現衝突時，一般情況是優先保證master分支新功能的程式碼。原因是新功能的程式碼多，邏輯也會複雜一些，而主觀上我們會認為preRelase分支上只留有一些小bug。這樣，我們按照這個邏輯，保證專案能夠編譯通過，merge就算結束了。
4. 但這樣其實是有隱患的，preRelase分支上的部分bug可能還在。
5. 如果要解決這個問題，我們應該怎麼做？那就只能花時間。首先merge時，不能使用快速合併，找到master分支功能的開發人員和修復bug的開發人員，一個一個對增、刪、改的程式碼進行取捨，這期間需要對程式碼邏輯、業務邏輯等進行討論，然後選出合適的方案。在這期間，最壞的情況是master分支和preRelase分支上某一個邏輯是對立的，必須捨棄掉一方的程式碼，也就是說這一方需要重新寫這一部分的程式碼。所以，我們是選這種方案，還是直接快速合併，後面如果遇到了問題，再修改呢？
6. 還有一點要注意的是，無論選擇哪種方案，我們的程式碼合併都應該先是從submodule開始的。也就是說一開始我們從master切preRelease分支的時候，也應該給藍芽模組切一個ble-preRelease分支。然後合併的時候，先合併藍芽模組的程式碼，再合併主專案程式碼。這樣一來，如果子模組一多，切preRelase分支，以及修改完bug的合併，不僅步驟繁瑣，而且邏輯也並不算清晰，應該怎麼解決呢？是這種分支策略不合適嗎？
7. 對於submodule的定義是不是有問題呢?是不是submodule得是穩定的，不需要更新的？還是說不應該選擇這種並行開發的策略？還是說有更好的分支策略？還是說現在的方法就挺好的,也不需要改什麼？