背景
在團隊多人協作開發中，分支管理需要解決如下問題：
- 直到上線並驗收通過之前，每個人開發的功能互不影響；
- 多人開發的功能測試時需要共用同一套（或有限的幾套）測試環境；
- 哪怕代碼上線後，也有回滾的可能性，上線回滾不會對主幹分支的代碼產生影響；
- 分支管理需要滿足快速小步迭代的敏捷開發需求；
我們團隊的每個項目有四套環境：
5. 開發環境：開發人員本機或者遠程開發環境（我們有幾個項目是通過 sftp 遠程開發）；
6. 測試環境：供測試人員使用；
7. 預發佈環境：類生產環境，上線前的迴歸測試使用；
8. 生產環境：正式發佈功能；
根據實踐，我們以 gitflow 爲基礎設計了自己的分支管理流程，該流程已經實踐 2 年了，效果很好。
分支管理流程
說明：
- 有 4 種分支：feature/fix、test、release、master。
feature/fix：開發分支/熱修復分支。當需要開發新功能或修復 bug 時，開發人員從最新 master 分支創建新的特性分支，在這些分支上進行開發和自測。格式：feature-主開發人姓名-特性描述，如feature-songlin-coupon-list。這種分支功能上線後即作廢，需不定期清理；test：測試分支。功能開發完成後，開發人員將 feature 分支合併到 test 分支，再將 test 分支發到測試環境供測試人員測試。test 分支屬於常駐分支，不過有時候因爲操作問題導致污染，需要刪掉當前 test 分支，然後從最新 master 創建新的 test 分支（test 重建）；release：功能測試驗收完成後，開發人員從最新 master 分支創建 release 分支，按日期命名，格式：release-年月日.當天版本號，如release-20200312.01。將 feature 分支合併到 release 分支，發佈到預發佈環境給測試驗收。預發佈驗收通過後，將 release 分支發佈到生產環境，生產驗收成功後將 release 合併到 master 分支。release 也是臨時分支，功能上線後即作廢；master：常駐分支，上面的代碼和生產環境保持一致。feature 和 release 都是從 master 分支創建的。不能在 master 分支上直接開發，正常情況下也不能用 master 分支發版。release 發佈到線上並驗證通過後，由項目負責人及時合併到 master 上；
釋疑：
-
爲何使用 release 分支發版而不是直接發 master？
主要有兩個原因。一方面，我們需要保證代碼直到在生產驗收通過之前都是和 master 隔離的，這樣一旦代碼有問題，不會污染 master，保證別人從 master 拉的代碼一定沒問題。
另一方面，該策略能解決多人發版時對 master 分支的競用問題。比如張三和李四都要發版（假設張三的發版分支是 release-20200401-01，李四的是 release-20200401-02），他倆協商後讓張三先發，於是張三的代碼先上預發佈迴歸，不料張三的代碼在預發佈發現了問題，而且需要較長時間修復，此時就可以直接讓李四發，由於張三和李四的發版分支是獨立的，互不影響。假設是使用 master 發版，那麼張三由於已經將代碼合到 master 了，此時對 master 造成了污染，需要回退。
再考慮另一個場景。張三開發了個大功能，現在正在預發佈迴歸，預計要兩天時間，此時線上突然出現了個緊急 bug 需要修復，由於張三的代碼沒有合到 master 上，李四就可以放心地從 master 拉 fix 分支去修復 bug，並插隊作緊急上線。
-
雖然 release 能解決並行發版問題，但可能會帶來發版覆蓋問題，如何解決？
由於代碼直到上線並驗收通過前都不會合併到 master 上，理論上會出現某人的發版忘記合到 master 上而導致後面的發版把前面的代碼覆蓋掉的情況。實踐中我們是通過管理手段來規避這種情況發生的。
首先，這種模式比較適合小團隊（10 人左右），大團隊需要劃分小組管理。
我們團隊的開發和發版都是有嚴格規範和審批流程的，開發人員要上生產的時候需要郵件申請，由團隊負責人審批。團隊負責人一般要做最終代碼審覈，其中重要的一項就是分支正確性檢查（這些工作可能是和項目負責人共同完成的）。另外每個項目都有具體的項目負責人，當有新功能上線並驗收通過後，由項目負責人將發版分支合併到 master 分支，並通知團隊中各成員，後面發版的需要同步 master 上的最新代碼。
比如前面說的張三和李四的情況，當李四的代碼（release-20200401-02）最終合併到 master 上後，張三需要將最新的 master 合到他自己的發版分支上（release-20200401-01），並重新申請預發佈迴歸。
相關
請參照我的另一篇技術團隊開發與發版規範