背景
當前公司使用的是gitlab做代碼版本控制桂对，由于目前部門已經(jīng)有了一套git分支管理流程，但不規(guī)范鸠匀，也沒有考慮多版本并行開發(fā)及持續(xù)部署的情況蕉斜，所以需要重新整理一下。目標是在盡量少的改動下實施好分支管理來滿足逐步增長的業(yè)務(wù)需求缀棍。
分支
由于持續(xù)集成已經(jīng)針對不同分支進行集成部署宅此，為了不改變持續(xù)集成的腳本，規(guī)劃三條長久分支
- master: 生產(chǎn)環(huán)境分支睦柴，保護分支诽凌，只有團隊管理者有權(quán)限合并毡熏，其他人提交需要提交PR坦敌。
- release: 測試環(huán)境分支，保護分支痢法，只有測試人員有權(quán)限合并狱窘，其他人提交需要提交PR。
- dev: 開發(fā)環(huán)境分支
規(guī)劃以下臨時分支
- feature: 功能分支财搁，針對一些比較獨立大的功能可以拉取功能分支蘸炸，測試上線完成后需要刪除。
- hotfix： bug修復(fù)分支尖奔，從master中拉取的分支搭儒，修正bug上線后刪除穷当。
開發(fā)流程
開發(fā)人員在dev分支進行開發(fā)，部分較大的feature開發(fā)需要單獨拉取分支進行開發(fā)淹禾。原則上提交到dev的代碼當天都可以編譯通過馁菜，需要設(shè)立一個隔夜發(fā)布(Nightly Deploy)的持續(xù)集成的定時任務(wù)。
測試流程
開發(fā)人員全部開發(fā)完成后铃岔，需要在gitlab上提交一個pull request汪疮，由測試人員進行review的pr進行merge。后面通過持續(xù)集成進行部署
生產(chǎn)流程
同測試流程毁习，合并到master后由運維同事進行生產(chǎn)部署智嚷。驗證完成后需要打tag，命名規(guī)則是tag-[version]-[date]纺且。
功能分支開發(fā)流程
本地拉取分支以后做功能分支開發(fā)盏道，也可以推送到遠程功能分支，需要開發(fā)完成后再合并回到dev隆檀，然后刪除feature分支
hotfix流程
當生產(chǎn)環(huán)境發(fā)現(xiàn)問題的時候摇天，可以從master中拉取hotfix分支。為了減低影響當前開發(fā)的情況恐仑，需要額外新建一個持續(xù)集成任務(wù)泉坐，專門針對hotfix分支部署測試環(huán)境。hotfix分支需要分情況進行處理
- 當目前開發(fā)版本暫時沒有部署到測試環(huán)境裳仆，可以直接把hotfix分支部署進行驗證即可
- 當目前開發(fā)版本已經(jīng)部署到測試環(huán)境腕让，需要評估一下其他中間件的修改（如數(shù)據(jù)庫修改）是否會影響bug功能的回歸。如果會歧斟，建議把bug合并到當前版本一起上線纯丸，如果不會，測試環(huán)境優(yōu)先部署hotfix版本進行部署静袖。
測試完成后觉鼻，按生產(chǎn)流程步驟進行操作即可，上線回歸完成后需要刪除hotfix分支
多版本開發(fā)流程
理論上最多兩個版本并行開發(fā)队橙，同時如果兩個版本能否并行開發(fā)也要做好前期的分析工作坠陈，比如是否前后有依賴，數(shù)據(jù)庫的增刪查改是否會相互影響等捐康。在評估沒有問題之后仇矾，再規(guī)劃保存代碼的分支如下
- dev: 先行版本的開發(fā)分支
- dev-after: 后行版本的開發(fā)分支
同時新建立持續(xù)集成的任務(wù)，專門針對dev-after分支開發(fā)環(huán)境部署解总。
