一个版本发布的案例

系统目前在捷克有一个分支版本在跑，版本号SPC200；在上海有另一个分支版本在跑，版本号SPC300；这2个分支上的代码已经收编合入主干，目前主干正在测试，版本号B100

目前计划在6月10日左右，用测试后的主干版本替换现场的SPC200和SPC300，同时需要开发一些定制需求，在6月25日左右交付到现场

所以项目组就需要考虑2个问题：

1、怎么开发定制需求
2、这段时间修改的BUG提交到哪个版本

首先回答第一个问题：

不能直接在分支上开发，因为在6月10日完成版本替换之前，分支还需要继续维护，现场发回的BUG，还需要在分支上出补丁。如果直接在分支上开发的话，就没有办法保证及时提供补丁

在主干上开发也不合适，因为定制需求的开发和主干上BUG的修改可能会互相冲突

所以就只能再拉出一个分支来做定制开发。问题是分支从哪里拉？

由于6月25日，定制需求是要合入主干再发布到现场的，如果是基于现有的分支再拉分支的话，到时候合入主版本就会很困难

所以选择从主版本上拉出分支来进行定制开发，就是目前最好的选择

最终方案：

从B100拉出分支SPC500，在这个分支上进行定制需求的开发，在主版本稳定之后，将SPC500的代码再合入主版本，在主版本上开发一个升级包，发到现场，SPC500作废

B100继续测试，测试完成之后发布到现场替换SPC200和SPC300

SPC200和SPC300在完成版本替换之前继续维护，发补丁到现场



总结：

1、当需要在不影响主干代码的情况下，开发新代码时，可以考虑拉一个短暂的分支，然后在合适的时候合入主干版本
2、最终要用什么版本发布，就从什么版本上拉出分支，可以减轻日后合入的工作量和难度

然后回答第二个问题：

目前BUG的来源有2个，一个是测试提的问题单，称为“测试问题”。一个是现场发回需要解决的问题，称为“现场问题”

最终的策略是：

对于“测试问题”，只在主干上修改，不在分支上修改
对于“现场问题”，需要在分支上修改并出补丁发往现场，并且同步在主干上也进行修改