本文分支策略為總結各中小型企業常見做法(僅代表個人觀點)，在下才疏學淺，文章如有缺漏或不當之處，望各位幫忙指正。寫此文也十分希望能起拋磚引玉之效。
據我所知，目前大部分無論是按瀑布/敏捷開發模型，就算伺服器資源十分有限的情況下，一套相對標準的研發流程也都應該至少具有開發(DEV)/測試(TEST)/生產(PROD)三個環境(叢集)。
環境說明
- 開發環境(DEV): 此服務環境一般為開發人員進行程式碼開發，單元自測，以及實驗的穩定環境。
- 測試環境(TEST): 開發人員提交測試後，將相關程式碼，服務環境部署到此環境，由測試人員對此環境的服務進行專業性的二次測試，例如基準測試，安全測試，業務邏輯驗證等等。
- 生產環境(PROD): 當測試環境得到充分的驗證之後並滿足釋出生產條件，會將相關程式碼，服務環境部署到此環境，提供正式服務。
分支說明
- feature(-xx)： 功能分支，每個功能分支應該代表著每個固定的迭代或開發功能集版本。
- dev: 開發分支(保護分支)，每次推送(
Push) 程式碼到此分支時，會觸發固定流水線(pipeline)，部署應用到開發環境。 - test: 測試分支(保護分支)，每次推送(
Push) 程式碼到此分支時，會觸發固定流水線(pipeline)，部署應用到測試環境。 - main(master): 主分支(保護分支)，不允許直接進行推送(
Push)操作，需要合併應當發起Pull Request(PR)，由負責生產環境的同事對此PR進行合併，此分支程式碼對應生產環境。 - hotfix: 緊急修復分支，俗稱救火分支，當生產環境發生問題需要緊急修改程式碼時，由開發人員從
main分支建立出來的新分支，在此分支上緊急修改程式碼後，合併到測試環境，測試驗證通過後，直接發起Pull Request(PR)提交到main；此分支一般在緊急修復線上問題之後，可將其合併(merge)到dev，再將此分支刪除。
單一功能迭代型分支策略
適用場景: 統一開發迭代版本，統一提測流程，統一上線流程
不適用場景: 多功能並行開發，多功能分別提測
適用人數：3-5人
流程圖說明
- 開發 : 所有開發人員均在統一迭代分支(
feature)上開發(包括修復bug)，在功能分支開發自測，單元測試無誤後並需要進行介面聯調時，合併(merge)到dev(開發分支)，觸發開發環境持續整合過程。 - 聯調 : 提交到開發環境進行前後端聯調，當聯調通過之後，按照約定時間進行前後提測(前後端可分別提測)，提測時，由開發人員將
dev(開發分支) 合併(merge)到test(測試分支)上，觸發測試環境持續整合過程。 - 提測 : 提交測試後，測試人員對測試環境進行驗證，測試中產生的bug，開發人員應該在
feature上面進行修復，然後統一按批次和時間進行重新推送(push)開發分支(dev)和合並(merge)測試(test)過程 - 上線 : 當測試環境程式碼已滿足本次迭代所有功能，並且所有測試中產生的bug全部修復得到驗證時，此時由研發負責人發起
Pull Request(PR)test -> main提交到，並編寫上線清單(包含上線資料指令碼，外部依賴服務，上線配置細節等等)，通知負責生產環境的同事合併，按照上線約定時間和上線清單進行上線。 - 修復 : 當線上遇到需緊急修復的問題時，由開發人員從
main分支建立出hotfix分支，在此分支上修改程式碼後，合併到測試環境，經過測試驗證通過後由研發負責人發起Pull Request(PR)hotfix -> main，進行緊急修復上線流程。
說明: 此分支策略下，feature分支可以看作為開發人員熟悉的local分支，feature,dev,test均允許互相合並(merge)
多功能並行迭代型分支策略
適用場景: 多迭代版本並行開發，分別提測流程，分別上線流程，差異化上線
不適用場景: 多並行開發版本中有交叉內容。
適用人數：3-5人和20人以上
流程圖說明
- 功能開發 : 開發人員按組在不同的對應迭代分支(
feature-xx)上開發(包括修復bug)，在功能分支開發自測，單元測試無誤後並需要進行介面聯調時，合併(merge)到dev(開發分支)，觸發開發環境持續整合過程；多功能分支可並行開發。 - 並行聯調 : 提交到開發環境進行前後端聯調，當聯調通過之後，按照約定時間進行前後提測(前後端可分別提測)，提測時，由開發人員將
feature-xx(功能分支) 合併(merge)到test(測試分支)上，觸發測試環境持續整合過程。 - 並行提測 : 提交測試後，測試人員對測試環境進行驗證，測試中產生的bug，開發人員應該在
feature-xx上面進行修復，然後嚴格統一按批次和時間合併(merge)開發和合並(merge)測試(test)過程，以避免頻繁釋出造成測試環境不穩定。 - 功能上線 : 當測試已滿足本次迭代所有功能，並且所有測試中產生的bug全部修復得到驗證時，此時由研發負責人發起
Pull Request(PR)feature-xx -> main，並編寫上線清單(包含上線資料指令碼，外部依賴服務，上線配置細節等等)，通知負責生產環境的同事合併，按照上線約定時間和上線清單進行上線。 - 修復 : 當線上遇到需緊急修復的問題時，由開發人員從
main分支建立出hotfix分支，在此分支上修改程式碼後，合併到測試環境，經過測試驗證通過後由研發負責人發起Pull Request(PR)hotfix -> main，進行緊急修復上線流程。
使用注意
- 此分支策略下，
dev作為開發環境公共驗證分支，test作為公共提測分支，feature-xx分支作為主要並行開發使用分支 ，最終會直接PR到main(主分支)， 開發人員務必最大程度保證此分支程式碼的穩定。 - 務必禁止開發人員對
dev和test進行相互合併(merge)；禁止任何從feature-xx -> main和hotfix -> main以外內容發起的Pull Request(PR) - 所有
feature-xx分支不可進行相互合併(merge)