版本需要強(qiáng)制控制的幾種常見場景

　　 ◆　要轉(zhuǎn)產(chǎn)或者上市了，不希望開發(fā)者隨意的代碼檢入影響到產(chǎn)品的質(zhì)量和穩(wěn)定性
　　 ◆　已經(jīng)轉(zhuǎn)產(chǎn)了，希望控制 Bug 的修改，不希望開發(fā)者隨意的代碼檢入影響到補(bǔ)丁（包）的發(fā)布

　　版本強(qiáng)制控制的手段

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

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

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

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

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

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

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

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

　　 ◆　修改了 Bug ，導(dǎo)致基線發(fā)生改變，希望將改變體現(xiàn)到已經(jīng)發(fā)生了改變的2.0版本中

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