APP開發程序員在使用代碼版本管理分支的時候，一般使用三種分支類型：主干分支、特性分支、發布分支，以及三條基本規則。

規則一，開始工作前，從主干創建特性分支。
 

每當開始一件新的工作項（比如新的功能或是待解決的問題）的時候，從代表最新已發布版本的主干上創建一個特性分支，然后在這個分支上提交代碼修改。也就是說，每個工作項（可以是一個人完成，或是多個人協作完成）對應一個特性分支，所有的修改都不允許直接提交到主干。

 

規則二，通過合并特性分支，形成發布分支。
 

先將已經完成的特性分支合并回公共主線（即開發分支），然后從公共主線拉出發布分支。
 

首先，發布分支的用途可以很靈活。基礎玩法是將每條發布分支與具體的環境相對應，比如release/test分支對應部署測試環境，release/prod分支對應線上正式環境等等，并與流水線工具相結合，串聯各個環境上的代碼質量掃描和自動化測試關卡，將產出的部署包直接發布到相應環境上。進階點的玩法是將一個發布分支對應多個環境，比如把灰度發布和正式發布串在一起，中間加上人工驗收的步驟。高級的玩法呢，要是按迭代計劃來關聯特性分支，創建出以迭代演進的固定發布分支，再把一系列環境都串在這個發布分支的流水線上，就有點經典持續集成流水線的味道了

其次，發布分支的特性組成是動態的，調整起來特別容易。在一些市場瞬息萬變的互聯網企業，以及采用“敏捷運作”的乙方企業經常會遇到這種情況，已經完成就等待上線的需求，隨時可能由于市場策略調整或者甲方的一個臨時決定，其中某個功能忽然要求延遲發布或者干脆不要了。再或者是某個特性在上線前發現存在嚴重的開發問題，需要排除。按往常的做法，這時候就要來手工“剔代碼”了，將已經合并到開發分支或者主干分支的相關提交一個個剔除出去，做過的同學都知道很麻煩。

 

規則三，發布到線上正式環境后，合并相應的發布分支到主干，在主干添加標簽，同時刪除該發布分支關聯的特性分支。
 

當一條發布分支上的流水線完成了一次線上正式環境的部署，就意味著相應的功能真正的發布了，此時應該將這條發布分支合并到主干。為了避免在代碼倉庫里堆積大量歷史上的特性分支，還應該清理掉已經上線部分特性分支。主干分支上的最新版本始終與線上版本一致，如果要回溯歷史版本，只需在主干分支上找到相應的版本標簽即可。