團隊專案的Git分支管理規範
原文地址： http://blog.jboost.cn/2019/06/17/git-branch.html
許多公司的開發團隊都採用Git來做程式碼版本控制。如何有效地協同開發人員之間，以及開發、測試、上線各環節的工作，可能都有各自的流程與規範。本文分享的是作者一直沿用的團隊專案Git分支管理規範，希望給有緣閱讀的人以參考，如果有更好的實踐，也歡迎探討、交流。
分支管理
建立專案時（一般是服務型專案，工具型或輔助型專案可以簡單一些），會針對不同環境建立三個常設分支：
- develop：開發環境的穩定分支，公共開發環境基於該分支構建。
- pre-release：測試環境的穩定分支，測試環境基於該分支構建。
- master：生產環境的穩定分支，生產環境基於該分支構建。僅用來發布新版本，除了從pre-release或生產環境Bug修復分支進行merge，不接受任何其它修改
平時開發工作中，會根據需要由開發人員建立兩類臨時分支：
- 功能（feature）分支：為了開發某個特定功能，從develop分支上面分出來的。開發完成後，要merge到develop分支。功能分支的命名，可以採用feature-*的形式命名(*為任務單號)
- Bug修復（fixbug）分支：為了修復某個bug，從常設分支上面分出來的。修復完成後，再merge到對應的分支。Bug修復分支的命名，可以採用fixbug-*的形式命名（*為bug單號）
流程規範
正常開發流程
- 從develop分支切出一個新分支，根據是功能還是bug，命名為feature-* 或 fixbug-*。
- 開發者完成開發，提交分支到遠端倉庫。
- 開發者發起merge請求（可在gitlab頁面“New merge request”），將新分支請求merge到develop分支，並提醒code reviewer進行review
- code reviewer對程式碼review之後，若無問題，則接受merge請求，新分支merge到develop分支，同時可刪除新建分支；若有問題，則不能進行merge，可close該請求，同時通知開發者在新分支上進行相應調整。調整完後提交程式碼重複review流程。
- 轉測時，直接從當前develop分支merge到pre-release分支，重新構建測試環境完成轉測。
- 測試完成後，從pre-release分支merge到master分支，基於master分支構建生產環境完成上線。並對master分支打tag，tag名可為v1.0.0_2019032115（即版本號_上線時間）
流程示意圖如下所示
並行開發測試環境Bug修復流程
並行開發（即前一個版本已經轉測但未上線，後一個版本又已在開發中並部分合併到了develop分支）過程中，轉測後測試環境發現的bug需要修復，但是develop分支此時又有新內容且該部分內容目前不計劃轉測，可以pre-release切出一個bug修復分支。完成之後需要同時merge到pre-release分支與develop分支。merge時參考“正常開發流程”。流程示意圖如下
生產環境Bug修復流程
生產環境的Bug分兩種情況：
- 緊急Bug：嚴重影響使用者使用的為緊急Bug，需立即進行修復。如關鍵業務流程存在問題，影響使用者正常的業務行為。
- 非緊急Bug或優化：非關鍵業務流程問題，僅影響使用者使用體驗，或出現頻率較小等，為非緊急Bug，可規劃到後續版本進行修復。
非緊急Bug修復參考“正常開發流程”。
緊急Bug修復，需要從master分支切出一個bug修復分支，完成之後需要同時merge到master分支與develop分支（如果需要測試介入驗證，則可先merge到pre-release分支，驗證通過後再merge到master分支上線）。merge時參考“正常開發流程”。流程示意圖如下
我的個人部落格地址：http://blog.jboost.cn
我的頭條空間： https://www.toutiao.com/c/user/5833678517/#mid=1636101215791112
我的github地址：https://github.com/ronwxy
我的微信公眾號：jboost-ksxy
————————————————————————————————————————
歡迎關注我的微信公眾號，及時獲取最新