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

規(guī)則一，開始工作前，從主干創(chuàng)建特性分支。
 

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

 

規(guī)則二，通過合并特性分支，形成發(fā)布分支。
 

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

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

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

 

規(guī)則三，發(fā)布到線上正式環(huán)境后，合并相應的發(fā)布分支到主干，在主干添加標簽，同時刪除該發(fā)布分支關聯(lián)的特性分支。
 

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