现在团队相关的一些背景：1、一个人维护几个系统；2、需求急且大小不一，产品经理也不会去细拆需求；3、敏捷成熟度几乎为0，没有DevOps，没有自动化测试；4、使用SVN。

将要变成：1、一个人维护更多的系统的；2、需求急且大小不一，产品经理变不了；3、引入一点点自动化；4、还是使用SVN。

开始：

一、引入Kanban，每天晨会，计划各系统版本。

二、如果版本时间小于3天（3天是经验值，并且各系统都可以不一样）直接主干开发和测试；如果版本时间大于3天，按版本号拉分支。

1、其实分支策略主要的一个目标笔者认为是减少master分支的冲突，当没人跟你冲突的时候，比如一个人维护几个系统都赶不过来时，就不用那么复杂分支又合并了。

2、但，一个人开发还面临另一个问题，就是需求不稳定。来源不稳定，大小不稳定。就会导致自己把自己冲突了，前面开发着的需求可能突然说不要了，或者紧急插入另一个需求。

3、所以这里会定一个开发时间，小于这个时间，那就直接冲什么都不要管就完事了。让你没反应过来我就上线了，真不要那就再提一个需求去下线，真还有紧急需求也等干完了这一发需求再说。

4、这个值受很多方面的影响，比如老板的忍耐程度、需求最小的颗粒度、自动化程度等。

5、那直接主干开发又怎么做呢？接下来介绍这个过程。Jenkins里配置一个主分支的任务，对应的就是代码主分支，执行如下几个过程：

5.1、svn checkout；

5.2、打包；

5.3、发测试环境并重启；

5.4、归档制品库；这里主要是模拟制品库的作用，一次打包，全流程使用（后面不要重打了）。

5.5、构建后进行静态检查；单独一个任务并且放到后面主要有两个考虑：1、可以设置定期执行；2、现在静态检查还未推行成为门禁，放后面可以让打包发布到测试环境更快。

三、如果版本的时间大于3，则需要进行分支操作。这时候在Jenkins里的SVN有个插件可以使用：svnmerge。安装此插件后按如下过程操作：

1、回到主分支的任务的配置页面，勾选如下选项并保存：

2、回到主分支的“状态”页面，这里左边的菜单栏里面会多出一个选项“Feature Branches”，点进去可以看到创建分支的功能：

Branch Name：分支名称，假设名称叫“XXX版本”，则创建成功后的Jenkins任务会命名为：主分支-XXX版本；

Commit Message：提交信息；

Branch Location：完整的SVN分支路径，一般是在 Branches下面，加上版本名称比如：http://XXX/Branches/XXX版本

3、Create成功后会有两个结果：3.1会在Jenkins里的想同目录里产生一个新的任务，任务里面的配置完全复制主分支的任务，除了svn的路径会被自动修改为分支的路径。3.2在SVN服务器上会自动从主分支里配置的SVN路径copy一份到Branch Location填写的路径，working-copy则可以使用小乌龟从这个路径里面拷贝下来开发了。

四、如果是分支开发，则每次转测的时候，需要把主分支合并到分支版本后，再打包。

这里暂时没有找到自动的方式（吐槽一下，SVN很古老的工具生态都快死光了，svnmerge这个插件有合并功能但不知道怎么配置，Jigomerge下载下来运行就出错，bat脚本的方式更是各种报错），只能用小乌龟手动执行了。

五、如果是分支开发，预发布（UAT）之前需要把所有的修改都从分支合并到主干上（同样的，用小乌龟合并吧），并且从现在开始用最短的时间使用Jenkins上主分支的任务进行打包、完整的回归测试、发布。

总结：不管用什么分支管理方式，整个过程主要关注几个点：

1、mater被独占的时间尽量少；

2、拉分支、合并代码带给开发的时间尽量少，能自动化尽量自动化；

3、能实现“一次打包、全流程不换包”则尽量遵守这个原则。但在分支场景下如果不信任工具自动合并代码的结果，那还是需要在预发布的时候做个包的切换，投入额外的时间进行全覆盖测试，不给master留下尾巴。