版本需要强制控制的几种常见场景

　　 ◆　要转产或者上市了，不希望开发者随意的代码检入影响到产品的质量和稳定性
　　
　　 ◆　已经转产了，希望控制 Bug 的修改，不希望开发者随意的代码检入影响到补丁（包）的发布版本强制控制的手段

　　 ◆　将需要保护的分支锁定（仅允许版本管理员修改），打上Release标签

　　 ◆　让开发者在以Release标签为基线的分支上进行开发

　　 ◆　登记开发者在以Release标签为基线的分支上的代码修改动作

　　 ◆　在以Release标签为基线的分支上发布版本进行集成测试

　　 ◆　对于集成测试通过的代码修改，通过版本合并手段合并到被保护的分支上

　　上面提到了版本合并，事实上，版本合并也有如下的几种常见情景

　　 ◆　修改了 Bug ，需要合并到基线版本中，以便可以发布稳定版本

　　 ◆　修改了 Bug ，需要合并到其他正在开发新功能的代码中

　　 ◆　修改了 Bug ，导致基线发生改变，希望将改变体现到已经发生了改变的2.0版本中

　　 ◆　4 1.1版本开发完成，1.0版不再维护，希望将1.1版本合并到基线版本中，作为以后开发新版本的基础