軟件開發的同學離不開代碼管理，git提供了工作流支持，github提供了倉庫&管理(當然還有其它一些免費或者收費的代碼倉庫)。
實際工作過程中，管理人員一般會根據項目實際需求來自定義一套適合協同開發的標準流程，以減少或者避免代碼沖突和事故，把風險降到最低。與此同時，還要清晰地確定開發、測試與發布流程，敏捷開發、快速迭代，保證整個項目成功上線。
倉庫代碼的分支介紹
????代碼倉庫：master主干分支
????開發：dev分支、feature分支(臨時性)
????測試：test分支、hotfix分支(臨時性)
????發布：release分支、特別定義的發版分支(臨時性)
倉庫代碼的架構設計
????一般中大型項目(3人以上)，一層代碼管理架構，建議設定四個分支：release-master-test-dev；二層代碼管理架構，建議基于一層基礎上增加臨時性分支(可選擇)：feature-hotfix-spec分支，如我現在正在進行的項目就采用了如下架構：
????若是基于1~3人開發維護的小項目，則可以簡化工作流(如下)，沒有必要搞得那么繁瑣，這樣減少維護成本，提供工作效率。
? ? 1）首先，砍掉二層架構的臨時性分支
????2）其次，把開發分支與測試分支合并，完全可在本地編譯、自測、聯調通過后，再上傳到dev分支
????3）最后，再協同開發時，主要提交代碼時開發人員間及時代碼同步+沖突解決
? ? 若是1人開發并維護的個人項目，則可以超簡化工作流(如下)，進一步把master與release分支合并，最終僅保留master+dev分支
代碼倉庫的CI&CD
代碼最終要經過內部測試與上線公測來檢驗其好壞強弱，并通過不斷進行地迭代、集成、發布才最終形成優秀的產品，這就需要進行持續的版本管理。
一般采用jenkins工具來做CI&CD，監控持續重復的工作并進行追蹤管理。CI的觸發原則上遵循以下條件：
1）發布分支(release/master)：強制在線觸發CI，并附帶tag+version迭代
2) 其它分支(dev、test...)：根據實際需要，可選擇性手動觸發CI，并附帶comment
