當下對於代碼的管理，主要采用GitLab或GitHub，然而使用git進行代碼管理過程中，一般有四種開發模式，分別為主干開發主干發布，主干開發分支發布，分支開發主干發布，分支開發分支發布。四種開發模式各有特色，下面將從針對四種開發模式進行一一說明。
但是針對微服務體系下，代碼的管理，一般建議采用分支開發主干發布。
1. 代碼管理模式
1.1. 主干開發+主干發布模式
模式特點：所有的操作都在主干上進行操作，隨着時間的演進，代碼只有一個版本，任何修改，均體現在主干上面，開發過程比較簡單。
操作權限：該種模式對於開發人員與項目經理等在代碼提交方面，權限相同；
適用場景：該種模式適用於團隊規模較小，業務模型明確，且人員技能較高的開發團隊。
1.2. 主干開發+分支發布模式
模式特點：所有的操作都在主干上進行操作，隨着時間的演進，代碼具有多個版本，運行多個版本可並行提供服務。
操作權限：該種模式對於開發人員與項目經理等在代碼提交方面，權限相同；
適用場景：該種模式適用於多版本並存，但只維護一個版本的產品，其他版本不進行維護的項目，該種場景較少。
1.3. 分支開發+主干發布模式
模式特點：所有的代碼提交都在分支上操作，隨着時間的演進，需要構建Release版本時，需要將代碼提交到主干上面，平常開發都是在分支上進行，好處可保證主干代碼始終可用。
操作權限：該種方式開發人員只具有開發分支權限，無master權限，代碼的merge只能由項目經理或有權人完成；
適用場景：該種模式適用於多功能並行開發，按照業務特性或模塊進行在分支進行開發，然后在進行合並后進行Release構建發布，業務場景較復雜，且人員素質層次不齊，需要代碼review。
1.4. 分支開發+分支發布模式
模式特點：所有的代碼提交都在分支上操作，隨着時間的演進，需要構建Release版本時，也是直接在分支上進行構建，各分支獨立演進，與主分支關系不大，是主干開發主干發布的一個組合使用。
操作權限：該種方式開發人員與項目經理一樣，只具有分支上的操作權限，不具有master權限。
適用場景：該模式適用於需求群/項目群的方式進行開發，大家公用同一個代碼庫，然后共享部門基礎代碼，然后各分支獨立進行演進。
2. 代碼管理規范
無規矩不成方圓，微服務架構下，代碼的管理一般采用git進行管控，因此，在使用git進行版本控制時，應遵循一些原則及規范。
2.1. 代碼管理原則
代碼管理的原則，用於確保代碼管理過程中不出現原則性錯誤，出現原則性錯誤，則會出現許多無用的操作，基本原則如下：
- 模式確實后，必須嚴格遵循執行；
- 提交代碼時，禁止代碼強制提交；
- 代碼提交時，必須進行注釋說明；
- 代碼提交時，必須按照規范執行；
- 出現沖突時，必須進行確認處理；
2.2. 代碼管理規范
由於微服務一般建議采用分支開發主干發布，因此，本規范主要針對分支開發主干發布模式，具體規范如下：
- 原則上代碼的開發提交，必須通過創建分支進行開發，特殊情況除外（bug），review同事有責任進行檢查其他同事是否遵循分支規范；
- 代碼提交前，必須先進行更新代碼（git pull），對於有沖突的文件，必須要進行對比，確認素有修改都是自己修改的，然后在進行提交，防止代碼回溯（即別人的代碼被覆蓋）；
- review同事遇到代碼刪除情況，必須與開發確認，是否為開發同事自己刪除，如果不是，很可能就是代碼回溯；
- 在代碼開發階段，代碼的提交盡量獨立化，也就是功能模塊盡量細分，每個開發負責一個模塊，盡量不要修改其他成員模塊代碼；
- 多人協作時，需要創建一個遠程分支，然后一起在遠程分支里協作開發，防止代碼回溯。禁止各自開發，然后線下發送文件合並；
- 代碼提交前，必須進行git pull，且進行git diff進行比對代碼，確保提交代碼為自己修改內容，防止出現代碼回溯；
- 代碼出現沖突時，必須 要與沖突代碼提交者進行確認沖突內容，雙方確認無誤方可處理；
- 主分支（master）為生產環境分支，除特殊情況（修復bug），禁止在master分支上進行開發；
- 代碼提交時，必須描述清楚做了什么，提交動作有add、update、remove，提交格式為[動作]+[操作的模塊信息，盡量詳細到具體的類名方法名]+[操作描述信息]，例如：git commit –m ‘update aa.java findByName 將精確查詢修改為模糊查詢’，每次提交盡量一個動作，多個動作請多次提交；
- 在git中，默認空目錄不會提交，如果某個空目錄想提交到版本庫，需要在該目錄下新建一個deleteme.txt的空白文件；
- 開發分支（developer）為開發分支，一般作為主要的代碼提交分支；
- 修復分支為修復bug分支，命名格式為bugfix-{date}，修復分支用於主要分支的bug修復工作；
- 功能分支為新增功能分支，命名格式為feature-{message}，可合並到developer分支；
- 其他分支，為特殊情況建立的分支，命名應帶有分支相關信息；