版本需要強制控制的幾種常見場景

　　 ◆　要轉產或者上市了，不希望開發(fā)者隨意的代碼檢入影響到產品的質量和穩(wěn)定性
　　 ◆　已經轉產了，希望控制 Bug 的修改，不希望開發(fā)者隨意的代碼檢入影響到補?。ò┑陌l(fā)布

　　版本強制控制的手段

　　 ◆　將需要保護的分支鎖定（僅允許版本管理員修改），打上Release標簽

　　 ◆　讓開發(fā)者在以Release標簽為基線的分支上進行開發(fā)

　　 ◆　登記開發(fā)者在以Release標簽為基線的分支上的代碼修改動作

　　 ◆　在以Release標簽為基線的分支上發(fā)布版本進行集成測試

　　 ◆　對于集成測試通過的代碼修改，通過版本合并手段合并到被保護的分支上

　　上面提到了版本合并，事實上，版本合并也有如下的幾種常見情景

　　 ◆　修改了 Bug ，需要合并到基線版本中，以便可以發(fā)布穩(wěn)定版本

　　 ◆　修改了 Bug ，需要合并到其他正在開發(fā)新功能的代碼中

　　 ◆　修改了 Bug ，導致基線發(fā)生改變，希望將改變體現到已經發(fā)生了改變的2.0版本中

　　 ◆　4 1.1版本開發(fā)完成，1.0版不再維護，希望將1.1版本合并到基線版本中，作為以后開發(fā)新版本的基礎