代碼分支定義規則

release

發版分支，只允許合并分支不允許提交代碼。所有任何需求上線必須使用release，上線前的測試回歸只能使用release回歸。UAT環境部署必須使用release分支。

master

線上穩定版本代碼分支，不允許任何人提交代碼到master，只允許合并release的代碼過來。release上線觀察一兩天確保穩定沒大問題后合并到master。

test 

測試環境共用的代碼分支，只允許合并分支不允許提交代碼。代碼在各自需求的開發分支開發好后再合并過來test分支提測。該分支代碼只允許進，不允許出。

dev

開發環境共用的代碼分支，只允許合并分支不允許提交代碼。代碼在各自需求的開發分支開發好后再合并過來dev分支聯調。該分支代碼只允許進，不允許出。

feat_{yymmdd}_{tapdId}_{var}

產品業務需求的開發分支，基于master分支拉取。{yymmdd}為6位數的年月日，是 評審需求時約定的期望上線時間，{tapdId}為tapd上的ID, {var}為自定義的參數，可不填。基于本規則，一個tapd需求對應一個開發分支。

fix_{yymmdd}_{tapdId}_{var}

線上問題修復的分支，基于master分支拉取。{yymmdd}為6位數的年月日，是約定的期望上線時間，{tapdId}為tapd上的ID, {var}為自定義的參數，可不填。基于本規則，一個tapd需求對應一個開發分支。

opt_{yymmdd}_{tapdId}_{var}

技術側優化需求的開發分支，基于master分支拉取。{yymmdd}為6位數的年月日，是約定的期望上線時間，{tapdId}為tapd上的ID, {var}為自定義的參數，可不填。基于本規則，一個tapd需求對應一個開發分支。

常規需求開發中各類型分支之間代碼流轉如圖

代碼合并

• 如果合并代碼時出現不可編譯的異常，則從對應的聚合分支拉fix分支出來修復再合并過去。

• 在開發分支開發過程中，大家務必保持每天都合一次master分支的代碼至當前開發分支，防止開發分支代碼落后太多導致合并上線時沖突太多、合并難度太大。
• gitlab上提交合并請求時別勾選“Delete source branch when merge request is accepted.” ，保留原分支。
• 開發分支只允許合并master分支代碼，不允許合并任何其他分支代碼。
• 開發分支合并到聚合分支，解決沖突應該這么操作： 假如開發分支是aaa，需要merge到test分支去。  步驟如下 1.基于開發分支aaa拉一個臨時分支temp。2.將臨時分支temp合并到聚合分支test。3.有沖突時，依據gitlab提示解決即可（gitlab的解決步驟就是先合并test到temp,然后再合并temp到test，就是在臨時分支解決沖突再合過去聚合分支test）。以上三步全程在gitlab上界面操作，這樣可以確保開發分支代碼是干凈的，不會合并到聚合分支的其他需求代碼。
• 理論上代碼在release又還沒上生產的時間是UAT集成回歸時間，時間跨度一般為一兩天。如果這一兩天時間內有線上bug需要緊急修復且要緊急上線，等不了release的常規發版時間。則規則如下：首先從master分支拉取fix分支用來修復bug，fix分支改好后先合到release分支，然后再使用fix分支發版。同時，release分支需要重新打包上UAT。以免release分支的包代碼落后。
• 注意：所有發版需求，都需先合到release再發版。合release應該先基于開發分支拉取一個releasetemp分支，然后再使用releasetemp合并到release分支。release和master的合并請勿使用temp操作。
• 所有的發版需求，都需要檢查打包之后到正式操作發版的時間區間，release是否有新的代碼提交。如有新的代碼提交合并，務必確認清楚這批新的代碼是否要上線，如果需要則需要重新打包。
• 提測時，需合一次master的代碼到開發分支再提測，保證代碼不要落后線上分支。
• 不小心合錯了還沒到發版時間的分支代碼到release分支咋辦？revert一下即可。下次想發版的時候發現分支代碼合不過去了，咋辦？對你上次的revert再執行一次revert即可。參考：//blog.csdn.net/cxn945/article/details/48372327

（TODO：發版系統部署UAT和生產時寫死release分支，不允許修改。測試環境固定test、開發環境固定dev）

bugfix緊急上線

CHANGELOG

代碼里應該維護一個Markdown格式的CHANGELOG，每次上線時記錄清楚變更。

服務版本管理人

擁有將代碼合并到master和release分支的權限。項目進UAT和上線時，需要去gitlab上發起申請合并請求，由版本管理人審批review后合并代碼到release分支。

上線成功后，觀察一段時間（至少一天），版本管理人合并release的最新穩定代碼至master。如果一天內服務又發生二次發布，則觀察時間順延一天。

Git代碼提交規范

在tapd的右上角，有個鏈接圖標，可以復制到源碼提交關鍵字。Git提交時使用該源碼關鍵字提交，這源碼關鍵字包含了tapd的id，務必確保按照規范提交，否則影響腳本自動檢查代碼是否有遺漏的判斷。具體操作參考

另外一個文件

（建立開發分支時務必保證按照規范命名，確保開發分支有帶上tapd的 ID）

打標簽

每上線一次打一次標簽。（可考慮發版工具里自動實現）

代碼合并方式

使用gitlab網站上的merge request操作。