SVN分支研究

在结合之前总结的定制开发的产品版本开发问题解决的方法：http://www.cnblogs.com/EasonJim/p/5971906.html，今天来研究以下用SVN处理这类的问题。

研究SVN分支合并的问题，只要用到trunk（主干）/branches（分支）/tags（标签），参考：http://www.cnblogs.com/EasonJim/p/6103807.html。

场景：

1、假设公司有一套电商产品，每个季度会发布一个版本，功能和底层上都是往上递增的。

2、那么问题来了，我们每个季度在发布每个新版本的同时，我们的销售也会不断的推广，可能在其中的一个版本就已经卖出去了。

3、由于客户更新版本的速度会没有那么快，毕竟是关乎钱的问题，可能会间隔几个版本之后才会选择更新一个版本，出这个版本钱去购买。

4、在第一次购买的电商产品的时候，里面就有属于自己的定制业务需求开发的功能，那么在购买最新的版本时候，必须包含最新的功能的同时也要包含自己以前定制开发的需求。

5、当在某个客户上开发的特定需求时，发觉这个特定需求也是属于我们产品需要的时候，那么会合并到我们的电商产品中，在下一个版本的发布上会带上这个功能。

基于以上场景，那么对于我们进行开发的时候，基于SVN的分支是最合适的。

分为以下版本：

主干（truns）版本A（不断的开发新功能，合并分支提交的bug）

分支（branches）版本A_1（其中发布的第A_1个用于销售的版本，并不断的在这个版本上进行开发修复bug，提交到主干，最后会发布第A_1、A_1.1、A_1.2...个版本到下面标签（tags）上）

标签（tags）版本A_1（其中发布的第A_1个用于销售的版本）

分支版本A_1_1（从tags或者branches上分支出来的A_1版本，客户1购买第A_1个版本，包含了自己的定制需求1）

分支版本A_1_2（从tags或者branches上分支出来的A_1版本，客户2购买第A_1个版本，包含了自己的定制需求2）

测试：

1、主干（truns）上的项目可以合并下面任何一个子分支的修改，包括子分支的子分支的修改。

1.1、子分支可以合并下面任何一个子分支的子分支的修改。

2、子分支的子分支的子分支可以合并子分支的修改。

3、子分支可以合并子分支的子分支的子分支的修改。

4、子分支（包括子分支的子分支...）可以合并主干（truns）的修改

所以，在SVN上分支出来的任何版本都可以来回合并。

总结：

那么应对上面的场景，我们对SVN可以这样控制：

1、大致版本控制和正常产品流程，参考：http://www.cnblogs.com/EasonJim/p/6103807.html。

2、当客户定制的功能符合产品的功能需要时，那么会提到最新的主干（truns）上，不会是合并到分支（branches）。

2.1、也可以这样处理，先从分支（branches）中分支出一个版本，然后这个功能合并到分支出来的版本中，再发布到标签（tags）中，那么以后就是维护这个版本了。

2.1.1、对于上面这种做法的场景就是，当主干已经从大版本1升级到了大版本2，那么只有分支（branches）是维护大版本1的，采用上面这样的方式就是最合适的。

3、当客户从版本1升级到版本3时，那么这个客户先合并版本3的分支（branches）的文件，最终形成客户定制的版本3。

3.1、另一种是直接签出版本3的分支（branches）的文件，然后再合并客户定制的版本1的定制功能，最终形成客户定制的版本3。

4、分支（branches）上的版本有修改的bug时，可以一同发布到标签（tags）上。

4.1、分支（branches）永远都只是修改bug，不允许新功能的开发。新功能全部交由主干（truns）进行。且修复的bug需要及时提交到主干。除非这个bug在主干（truns）上的功能已经砍掉了，那就不用提交。

5、分支（branches）修复了一个bug的同时，发布到标签（tags）的同时，可以在针对相应的版本发布到分支（branches）上，也可不用，因为销售出去的产品用于都是最新的版本的（不可能直接销售时拿这个版本以前有bug的进行销售吧，所以肯定是最新没bug的版本才对）。

6、其实还有一个特别的需求，比如，分支（branches）上的某个V1版本需要增加功能（短信验证），而这个功能是在主干的最新V2版本上有加入，但是迫于用户只愿意给这个短信的钱，不愿意给V2升级版的钱。且这个短信验证的功能在V1这个版本也确实需要的时候。

6.1、第一种解决，针对这个用户定制开发。不考虑合并到分支（branches）上。

6.2、第二中解决，打破上面第4点，然后在分支（branches）V1版本直接合并主干（truns）的短信验证功能进来，再发布一个增加短信功能的V1版本到标签（tags）上。注意，这里版本号上的功能增加+1。

6.3、第三中解决，打破上面第4点，然后在分支（branches）V1版本上开发短信验证的功能，然后客户定制的V1版本上合并分支（branches）V1版本的短信功能。

总结2：

有了SVN的代码控制，那么再针对版本号进行命名进行规范：http://www.cnblogs.com/EasonJim/p/6105893.html