咱們採用目前的保留的分支體系： master 、 develop（將feature、hotfix合到develop）、release測試
1、代碼分支url
| 分支.net |
說明3d |
建立來源分支code |
代碼來源blog |
目標分支生命週期 |
代碼輸入方式開發 |
生命週期文檔 |
命名規則★get |
| ★master |
主幹分支，一般做爲代碼基線，全部發布的代碼最終都會合併到此分支。 |
無 |
release、hotfix |
develop |
Pull request |
長期 |
Master |
| ★develop |
開發分支，一般做爲其餘分支的源分支，也最終會合並回此分支 |
無 |
feature、 release、hotfix |
develop |
Pull request |
長期 |
Develop |
| feature |
功能分支，用於爲將來的應用版本開發新的功能需求 |
develop |
developer |
develop |
Merge |
併入目標分支後，刪除 |
Feature/{jira_issue_key} |
| ★release |
發佈分支，用於輔助新版本發佈的準備工做，例如小bug的修復，或者版本號的修改等等 |
develop |
developer、 hotfix |
Develop、master |
Merge |
併入目標分支後，刪除 |
Release/{jira_issue_key} |
| hotfix |
修復分支，用於正式版本的緊急修復 |
master |
開發者 |
Develop、master、release |
Merge |
併入目標分支後，刪除 |
Hotfix/{jira_issue_key} |
2、功能開發
|
|
研發 |
測試 |
審查 |
| 建立並推送功能分支 |
√ |
|
|
| 建立 feature → develop 的 pull request |
√ |
|
|
| 代碼審查 |
|
|
√ |
| 功能測試 |
|
√ |
|
| 合併代碼到開發分支 |
|
|
√ |
| 關閉pull request |
|
|
√ |
3、版本發佈
|
|
研發 |
測試 |
審查 |
| 建立並推送發佈分支 |
√ |
|
|
| 建立 realease → develop 的 pull request |
√ |
|
|
| 建立 realease → master的 pull request |
√ |
|
|
| 審查 realease → develop 的 pull request |
|
|
√ |
| 審查 realease → master 的 pull request |
|
|
√ |
| 發佈測試 |
|
√ |
|
| 合併代碼到開發分支 |
|
|
√ |
| 合併代碼到主幹分支 |
|
|
√ |
| 關閉realease → develop 的 pull request |
|
|
√ |
| 關閉realease → master 的 pull request |
|
|
√ |
| 建立代碼標籤 |
|
√ |
|
|
|
研發 |
測試 |
審查 |
| 建立並推送修復分支 |
√ |
|
|
| 建立 hotfix → develop 的 pull request |
√ |
|
|
| 建立 hotfix → release 的 pull request |
√ |
|
|
| 建立 hotfix → master的 pull request |
√ |
|
|
| 審查 hotfix → develop 的 pull request |
|
|
√ |
| 審查 hotfix → release 的 pull request |
|
|
√ |
| 審查 hotfix → master 的 pull request |
|
|
√ |
| 發佈測試 |
|
√ |
|
| 合併代碼到開發分支 |
|
|
√ |
| 合併代碼到發佈分支 |
|
|
√ |
| 合併代碼到主幹分支 |
|
|
√ |
| 關閉hotfix → develop 的 pull request |
|
|
√ |
| 關閉hotfix → release 的 pull request |
|
|
√ |
| 關閉hotfix → master 的 pull request |
|
|
√ |
| 建立代碼標籤 |
|
√ |
|
5、場景模擬
Master分支 ：必定是最後一次 commit已經上線，或者 他已經順利經過了 QA、PD、PO 的打磨鍛造，分分鐘拔出來上線。（ps：不用怕會祭天）
（1）常規開發
新建code庫，庫中 master和全部其餘分支，只有項目負責人有寫入權限
從code庫中master克隆一個分支出來，命名爲：branch_1.0.0 【develop】
開發人員在 此分支上修改，開發和自測完後，向 code庫發起pull request，請求代碼審查和合並
pro-master 進行代碼審查、合併後，提交測試。頭缺陷，繼續在 branch_1.0.0 修復，而後發起pull request，如此循環，知道最後，測試完成，能夠將 branch_1.0.0 上線
上線後，將此branch_1.0.0分支合併到msster，並給branch_1.0.0打上tag。 【ps：理論上，此時的 master和branch_1.0.0是徹底一致的】
（2）並行開發
假定：branch_1.0.1 和 branch_1.0.2 同時並行開發
狀況：
第一種： branch_1.0.1 先開發完，測試完，上線完以後，branch_1.0.2 才準備提測。 此時，須要在合併測試版本branch_1.0.2時，將master內容一塊兒合併，合併以後再進行測試
第二種： branch_1.0.1 和 branch_1.0.2 同時開發完，能夠合併成一個release版本， 或者 合併成到 branch_1.0.2 進行測試
第三種： branch_1.0.1 開發完，測試完，未上線，branch_1.0.2 開發完，準備提測， 此時 操做和 第二種同樣
第四種： branch_1.0.1 和 branch_1.0.2 都開發完，須要同時測試（不建議），只能一個分支先測試完上線，另外一個分支須要合併上線後的master再次測試，上線。
參考文檔：https://blog.csdn.net/BoReFrontEnd/article/details/97391441