此文为上一篇文章的后续
我们来回顾一下，现在，你的小组负责的系统，有主干分支，每次新的需求，你都从主干(formal)拉取分支(dev-日期-需求名)进行修改，自测通过后，合并至测试分支(test)进行提测，测试通过后，再合并至正式分支等待发布，每次发布时，拉取最新部署分支(formal-2.x-0)进行部署，如果需要在已部署分支进行修改，将此需求合并至对应分支，再修改版本进行发布
随着签约的客户越来越多，提出的需求越来越多，导致开发分支越来越多，是时候删除一部分历史的开发分支了，但是删除这部分分支，意味着这些需求再往历史部署版本进行合并将比较复杂，哪些可以删除，哪些暂时还不好删除，很难判断，此时你不得不引进一个维护版本系统来记录你拉取了哪些分支，以及这些分支已经合并到哪些版本里了
领导找到你了，觉得你负责的系统做得很好，所以这个需求维护系统由你负责开发，并由你们的系统进行试用。
你做了初步的设计：
每个需求尽量拆解，拆解后的需求分别进行维护，使用一条需求记录表(demand)进行记录，表中除了需要有需求简述，需求描述，创建时间，完成时间，开发人员，开发状态等字段外，合并至主干时版本，合并其他版本版本号
维护客户表(client)，维护客户部署系统表(client_system)，表中有客户ID，部署系统，系统版本号
维护版本表(version),表中维护版本ID，发版时间，版本分类(主干版本，分支版本)

做好如下约定，主干版本为formal-2.x.0，x自增，分支进行迭代时，在原版本基础上，只修改最后一位，如：formal-2.10.2改为formal-2.10.3(可能为4)，防止维护版本较多，处于相同版本下的多个客户，如果此时D客户版本为formal-2.10.3，而此时最新分支版本为formal-2.10.5，此时如果升级，要么升级为formal-2.10.6.要么升级成最新的主干版本formal-2.x.0。特殊客户除外，拉取新分支，版本新增客户简称，如：formal-2.10.nzs，维护知道客户更新大版本为止
整体流程如下：
1、维护所有现有客户A\B\C\D\E\F\G…
2、在版本表中创建基准版本3.0.0(早于此版本的客户，分批更新至此版本或之后版本)，并在之后每次发布时进行版本维护.；
3、客户E提出新需求a\b\c\d，需求记录表中插入对应记录，创建对应分支进行开发(可以进行联动，即需求录入后，只要开发评审通过，自动拉取开发)
4、测试通过后，修改需求表状态(待发布)
5、版本发布时(可以把版本发布和部署分支拉取自动化处理，自动拉取部署分支)，选择待发布中的需求，进行版本发布，需求表状态自动修改为已发布，自动同步“合并至主干时版本”
6、如需发布分支版本，选择分支版本，选择需求，进行发布(此处也可以自动化，但是cherrtpick容易冲突，最好还是手动进行)，需求新增“合并其他版本版本号”记录
7、定时判断，如果一个需求，在所有客户的版本里(不是所有版本，是客户的版本)，都有，则进行标记，择机进行淘汰处理

以上操作，还有一些不足，比如：1、就算如此，还是会维护很多分支；2、开发分支合并至主干基本不会有问题，但是会出现，往旧部署分支合并时，异常，如：该分支基于其他分支开发，此分支没有合并至旧部署分支
建议：客户更新，尽量更新至最新版本；任何系统都不能脱离人存在，需要有对系统掌握度高，这个人，最好是你
最后，进行更新时，又出现一个问题，版本跨度太大，好多表都有调整，测试进行回归测试时，各种因为表结构问题导致的报错，如何修改