微服務架構下程式碼管理規範
當下對於程式碼的管理，主要採用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分支；
- 其他分支，為特殊情況建立的分支，命名應帶有分支相關資訊；