?本文目的：

實現多個項目同時進行的git多版本管理工作流。

? ? 名詞解釋：

?????????feature-XXXX：特性分支指CCS中一個項目或者一個迭代，在該分支上開發，完成后，合并，最后，刪除該分支，開發人員(xxxx可以自己根據該分支)develop?：開發分支，開發環境基于該分支構建，開發人員關注該分支，一個大融合分支，該分支體現了此時進行的所有項目的特性功能。test（release）：測試分支，測試環境基于該分支構建，測試人員關注該分支，該分支包含即將上線的特性功能。hotfix：為了修復某個bug，從master分支上面分出來的。修復完成后，再merge到master分支以及其他分支master：生產環境穩定分支，生產環境基于該分支構建

目前現狀：

3、產生問題：

? ?從上圖可以看出 當前分支管理無法實現 多版本并行開發，是一個串行的工作流方式。

? 1、當某個迭代在develop分支完成生命周期即封板后，此時代碼進行到test分支，發現代碼有bug

? ? ? ?目前所見做法有 部分開發者直接在test分支修改代碼，develop分支不修改，等到上線后master反合；部分開發者在test修改后，develop同時改掉。

? 2、同時有 A、 B ?2個迭代， A迭代計劃先上線，B迭代計劃在A后面上線，只能A迭代生命周期進行到test才能釋放出develop分支給B迭代使用。

? 3、同時有 A、 B ?2個迭代， A迭代計劃先上線，B迭代計劃在A后面上線，突然接到通知B需要在A前面上線，此時A占據著測試環境，需要增加很大工作量回退代碼。

上述問題大大影響了開發效率，測試效率，也會產生代碼丟失的風險等。

解決方案

?解決方案-工作流圖：

? ? ? ??

流程圖解釋：

??1、場景

????項目同時并行?：1、迭代33?；?2、迭代22開發?這2個項目；

?2、準備

????從master拉出2個分支?feature-迭代33??2、feature-迭代22。

3、開發自測聯調階段（feature->develop）

???3.1、??負責這2個項目的開發人員在各自這2個分支上開發。3.2、開發完成，想到環境上驗證自己開發東西是否ok或者和前端進行聯調。可以將各自分支上的代碼merge到develop分支，此時以develop分支部署開發環境，就具有了這2個項目的所有特性；3.3、如果開發環境驗證時發現存在bug，此時修改代碼請在各自的feature分支上修改，修改完成再將自己的分支代碼merge到develop環境，部署一下驗證。

4、提測階段(feature->test（release分支）)

?4.1、到此階段前后端已經聯調完畢，自測Ok需要發起測試驗證即提測，此時迭代22開發在迭代33前上線，保險起見將master分支反合到該特性分支（feature-迭代22）以及test分支，
再將test分支代??碼反合到feature-迭代22分支（這么做減少沖突）最后將feature分支merge到test分支，部署test分支提測。4.2測試過程中發現bug，在各自分支修改，修改后合并到test分支，再部署驗證，別忘了也merge到develop分支。驗證?ok，選取時間點上線。

5、上線階段(test（release）->master)

可以拿test（release）分支上線，記住上完線要反合master分支，打tag

說明：在第4步中，應該有一個release分支，但是因為環境不支持等原因，以固定的test分支代替其作用；