Git開發規範
日常開發中，我們經常會跟
Git打交道，可能服務器不一樣，但是命令和規範基本都是一樣的。
一.常駐分支
常駐分支爲一個正常開發上線流程應該會有的分支。
1.master/prod/production
主分支，又稱爲生產環境分支，有時可能會使用（prod/production）來代替，生產環境的部署分支，生產環境相關操作，如：打包等應從改分支進行。
2.dev
全稱（Develop），開發分支，我們正常的需求開發等，應該使用該分支。開發環境的部署和打包，使用該分支。
3.pre
全稱（Pre production），預生產分支，一般根據項目而定，有的項目可能因爲資源不足等原因，沒有預生產分支，預生產分支，又爲線上測試環境。預生產環境打包應從此分支進行。
二.臨時分支
臨時分支，顧名思義，是不會常駐的，一般，在merge完，完成使命後，會被刪除。
1.feature
新需求的開發分支，從develop分支上面分出來的。開發完成後，要merge到develop分支。功能分支的命名，可以採用feature_*的形式命名(*爲需求名稱拼寫，如feature_user_list)
2.hotfix
Bug修復分支。爲了修復某個bug，從常駐分支上面分出來的。修復完成後，再merge到對應的分支。Bug修復分支的命名，可以採用fixbug_*的形式命名（*爲bug說明，如fixbug_user_list）
三.開發流程
1.正常開發
- 從
dev分支切出一個新分支，根據是新功能還是bug，命名爲feature_*或fixbug_*。 - 開發者完成開發，提交分支到遠程倉庫。
- 開發者發起
merge請求（可在gitlab頁面New merge request），將新分支請求merge到develop分支，並提醒代碼檢查人員進行review。 代碼檢查人員對代碼review之後，若無問題，則接受merge請求，新分支merge到develop分支，同時可刪除新建分支；若有問題，則不能進行merge，可close該請求，同時通知開發者在新分支上進行相應調整。調整完後提交代碼重複review流程。- 轉測時，直接從當前
develop分支merge到pre分支，重新構建測試環境完成轉測。 - 測試完成後，從
pre分支merge到master/prod分支，基於master/prod分支構建生產環境完成上線。並對master分支打tag，tag名可爲v1.0.0_2020.05.15.1（即版本號_上線時間）
2.開發過程中，修復Bug
即前一個版本已經轉測但未上線，後一個版本又已在開發中並部分合併到了dev分支，轉測後測試環境發現的bug需要修復，但是dev分支此時又有新內容且該部分內容目前不計劃轉測，可以從pre切出一個bug修復分支。完成之後需要同時merge到pre分支與dev分支。
3.生產環境Bug修復
生產環境的Bug分兩種情況：
緊急Bug：嚴重影響用戶使用的爲緊急Bug，需立即進行修復。如關鍵業務流程存在問題，影響用戶正常的業務行爲。非緊急Bug或優化：非關鍵業務流程問題，僅影響用戶使用體驗，或出現頻率較小等，爲非緊急Bug，可規劃到後續版本進行修復。
修復緊急Bug：
：需要從master分支切出一個bug修復分支，完成之後需要同時merge到master分支與dev分支（如果需要測試介入驗證，則可先merge到pre分支，驗證通過後再merge到master分支上線）。
四.流程圖
