关于版本、分支的一些总结

自从系统发布到现场使用之后，就有几个分支同时运行。最近对相关问题有一些思考，在此总结一下：

1、版本

确定要做定制需求开发的时候，是3月15日，确定下来第一批需求的交付时间，是4月10日。当时主版本还在TR5阶段，而且版本还很不稳定。

在这种情况下，在主版本上做定制需求的开发是不合适的。因为：

首先，主版本一直在修改问题合入代码，而定制需求开发也需要合入大量代码，这必定会有冲突。可能造成主版本无法按时转测试，也可能造成定制需求的延误。

其次，以当时的版本状况，主版本不可能在4月10日发到一线使用，所以即使在主版本开发，也无法把主版本发出去。

因此唯一的选择，就是在主版本上拉出分支。主版本继续修改问题，在分支版本上开发定制需求，在4月10日，将分支版本发到一线。

最终是从B080拉出分支SPC200T和SPC300T，分别进行捷克和上海2个局点定制需求的开发。

----------------------------------------------->主版本（B080）

----------------------------------------------->SPC200T（基于B080）

----------------------------------------------->SPC300T（基于B080）

接下来在4月10日，第一批定制需求发到一线，需要进行第二批需求的开发，计划在5月10日以升级包的方式发布到一线

同时，这时候还有一件事情，对最终的措施有重要影响：即每周需要针对一线发现的问题出补丁。

为什么这件事情很有影响呢，因为如果说当时的策略是，一线发现的问题，在5月10日的升级包里一起解决的话，那么我们就可以直接在SPC200T和SPC300T上修改，同时进行定制需求的开发，然后在5月10日一起提供升级包

或者甚至当时的策略是，一线发现的问题，在用主版本做版本替换的时候解决就可以的话，那么连SPC200T和SPC300T都不需要改了，这2个分支只需要做定制需求开发，一线发现的问题在主干上修改就可以了

既然确定是每周要出补丁到一线，那就没法直接在SPC200T和SPC300T上进行问题修改了，否则的话补丁内容就会与第2批定制需求的内容相互冲突。
所以这时候，就在SPC200T和SPC300T上又拉了一个短暂的分支。在SPC200T和SPC300T上继续做第2批定制需求的开发，在分支上出补丁到一线

----------------------------------------------->主版本（B090）

----------------------------------------------->SPC200TB011

------------------------------->SPC200T分支（基于SPC200TB011）

----------------------------------------------->SPC300TB011

                             ------------------------------->SPC300T分支（基于SPC300TB011）

然后在5月10日发布第2批定制需求的时候，把SPC200T分支和SPC300T分支上修改的问题，都合入了SPC200T和SPC300T，连同第2批定制需求一起发到一线。SPC200T分支和SPC300T分支销毁

这时候版本线又恢复成这样：

----------------------------------------------->主版本（B110）

----------------------------------------------->SPC200TB021

----------------------------------------------->SPC300TB021

这个时候主版本基本稳定，计划在6月上旬用主版本替换一线的分支版本，所以将SPC200T和SPC300T上的前2批定制需求代码合到了主干里。

但是在版本替换结束之前，还是需要出补丁支持一线，所以SPC200T和SPC300T还是需要保留

同时，要开始开发第3批（最后一批）定制需求了，出于同样的原因（不影响主干测试、不影响分支出补丁），又基于B110拉出一个分支SPC500T专门做第3批定制需求的开发，所以版本线变成下面这样：

----------------------------------------------->主版本（B110）

----------------------------------------------->SPC200TB021

----------------------------------------------->SPC300TB021

----------------------------------------------->SPC500T

这就形成了4个版本同时存在的情况：
主版本已经合入了前2批定制需求的代码，正在继续测试过TR5

SPC200T和SPC300T继续保留，为了出补丁支持一线，这条线上修改的问题，要同步合入到主干版本中

SPC500T专门进行第3批定制需求的开发

然后在6月上旬，用主版本替换掉一线的分支版本，到此时SPC200T和SPC300T就废弃了。接下来把SPC500T上的定制需求合到主版本上，基于主版本出升级包。然后将升级包发布到一线，SPC500T也废弃了。以后一线就只有一个版本，所有问题都只在主线上修改，版本线变成下面这样：

----------------------------------------------->主版本（TR5）

以上就是此次定制需求开发、收编、主版本过点这些活动背后的版本走向

2、分支

确定分支策略，一个很关键的因素是发布的计划。或者说，发布计划就是版本计划

一个分支等于一套代码，分支越多，维护成本就越高。所以分支的数量不能太多，存在的周期也不宜太长。拉出了分支以后要尽快地收编合入主干版本，减少维护的工作量

分支上的修改一定同步到主干上（可能是第一时间同步，也可能是晚一点同步），但是反之，主干上的修改，则不一定要同步到分支上。可以看作一个树形，比如下图：

----------------------------------------------->主版本（B090）

----------------------------------------------->SPC200TB011

------------------------------->SPC200T分支（基于SPC200TB011）

----------------------------------------------->SPC300TB011

                             ------------------------------->SPC300T分支（基于SPC300TB011）

比如在SPC200T分支上发现一个问题，那除了要在SPC200T分支上修改（为了第一时间出补丁）之外，还需要在SPC200TB011和B090上同步修改，否则稍后替换的时候，修改过的问题就会被覆盖掉

但是如果是在B090上发现的问题，如无特殊情况，则不需要向下同步到SPC200TB011和SPC200T分支上