團隊專案的Git分支管理規範

【空山新雨】發表於2019-06-18
Git

原文地址： http://blog.jboost.cn/2019/06/17/git-branch.html

許多公司的開發團隊都採用Git來做程式碼版本控制。如何有效地協同開發人員之間，以及開發、測試、上線各環節的工作，可能都有各自的流程與規範。本文分享的是作者一直沿用的團隊專案Git分支管理規範，希望給有緣閱讀的人以參考，如果有更好的實踐，也歡迎探討、交流。

分支管理

建立專案時（一般是服務型專案，工具型或輔助型專案可以簡單一些），會針對不同環境建立三個常設分支：

  1. develop：開發環境的穩定分支，公共開發環境基於該分支構建。
  2. pre-release：測試環境的穩定分支，測試環境基於該分支構建。
  3. master：生產環境的穩定分支，生產環境基於該分支構建。僅用來發布新版本，除了從pre-release或生產環境Bug修復分支進行merge，不接受任何其它修改

平時開發工作中，會根據需要由開發人員建立兩類臨時分支：

  1. 功能（feature）分支：為了開發某個特定功能，從develop分支上面分出來的。開發完成後，要merge到develop分支。功能分支的命名，可以採用feature-*的形式命名(*為任務單號)
  2. Bug修復（fixbug）分支：為了修復某個bug，從常設分支上面分出來的。修復完成後，再merge到對應的分支。Bug修復分支的命名，可以採用fixbug-*的形式命名（*為bug單號）

流程規範

正常開發流程

  1. 從develop分支切出一個新分支，根據是功能還是bug，命名為feature-* 或 fixbug-*。
  2. 開發者完成開發，提交分支到遠端倉庫。
  3. 開發者發起merge請求（可在gitlab頁面“New merge request”），將新分支請求merge到develop分支，並提醒code reviewer進行review
  4. code reviewer對程式碼review之後，若無問題，則接受merge請求，新分支merge到develop分支，同時可刪除新建分支；若有問題，則不能進行merge，可close該請求，同時通知開發者在新分支上進行相應調整。調整完後提交程式碼重複review流程。
  5. 轉測時，直接從當前develop分支merge到pre-release分支，重新構建測試環境完成轉測。
  6. 測試完成後，從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分兩種情況：

  1. 緊急Bug：嚴重影響使用者使用的為緊急Bug，需立即進行修復。如關鍵業務流程存在問題，影響使用者正常的業務行為。
  2. 非緊急Bug或優化：非關鍵業務流程問題，僅影響使用者使用體驗，或出現頻率較小等，為非緊急Bug，可規劃到後續版本進行修復。

非緊急Bug修復參考“正常開發流程”。

緊急Bug修復，需要從master分支切出一個bug修復分支，完成之後需要同時merge到master分支與develop分支（如果需要測試介入驗證，則可先merge到pre-release分支，驗證通過後再merge到master分支上線）。merge時參考“正常開發流程”。流程示意圖如下

生產環境Bug修復流程





我的個人部落格地址：http://blog.jboost.cn
我的頭條空間： https://www.toutiao.com/c/user/5833678517/#mid=1636101215791112
我的github地址：https://github.com/ronwxy
我的微信公眾號：jboost-ksxy

————————————————————————————————————————

微信公眾號
歡迎關注我的微信公眾號，及時獲取最新分享

相關文章