最近公司产品上线,整个系统架构包含有七八个子系统,并且子系统都是集群部署。所以每次升级维护都要确保尽可能不出问题。因为整个系统刚上线不久,意味着新系统不定期有BUG需修复,但新功能模块也在持续的开发中(可能持续的时间还不短),所以就引发一个问题:持续开发的新功能代码与生产上的代码 如何进行隔离开来进行维护,而且二者还需要不定期的合并代码。所以就研究了下SVN分支。

首先需厘清SVN的分支以下几个概念:

trunk: 主干(可以理解为开发环境的代码,平常做开发的工作目录)

branches:从主干拷贝了一份代码重新在svn服务器上的建了个分支目录(通常叫branch,一般与生产上的代码保持同步)

tag:主干版本标记(标识每次大的升级版本号)。

我们项目目前的版本管理策略如下(可以根据自已的项目实际需要建立不同的版本管理策略):

1、系统在没有上线之前,只有一个主干(trunk),所有开发人员在主干上进行协同开发。

2、系统上线之后,在主干的基础上创建一个分支,该分支上主要用于修复生产环境的BUG,或者紧急新功能上线。主干仍然进行新功能模块的开发。

3、每次生产环境的升级,都从分支上进行打包部署。升级完之后需将分支上改动的代码及时合并到主干上(开发人员常常忘记,切记)。

4、新功能在主干上开发好了,需要进行一次大的升级,可以先将主干打上一个TAG做为大版本号,并且同时在此基础上创建一个对应的分支,然后切换到分支上进行打包部署,这个版本的生产代码维护也在分支上。

原则:分支用于生产代码维护,主干用于平时开发,TAG用于主干大版本的标记。

由于我们项目由好几个子系统构成一个大的集群系统,系统之间的版本统一就显得很重要。所以每次上线,即使相关子系统没有代码改动,也需要重新建立一个分支版本以适应其它子系统的版本改动。

说了这么多之后,来说下具体分支合并到主干上的操作,因为这部分最容易出错:

合并根据目标不同分为2种:

1、分支合并到主干:主要用在修复完生产BUG,并上线之后。需把改动的代码合并到主干上。

2、主干合并到分支:公用的逻辑改动,需反映到所有并行的分支上。

注意:合并是要在目标目录上进行操作的,如:分支合并到主干(主干为目标),需切换到主干上操作合并功能,主干合并到分支(分支为目标),需切换到分支上进行操作。

分支合并到主干的具体步骤:

1、主干目录右键选择合并

eclipse svn 分支合并到主干-LMLPHP

 出现以上6个合并选项,

第一个选项:合并指定的版本,可以是从分支合并到主干,也可以是主干合并的版本,主要作用把分支的部份修改合并到主干上。

第二个选项:复兴分支,这里会把分支上所有的需改都合并到主干上。如果只想合并修改的一部分,并适合这项。

第三个选项:将主干上的修改合并到分支。

第四个选项:2个不同的分支合并,但其实也可以是分支和主干的合并,只要from选择为主干就行。

通常选择第一项或第四项进行操作,这里需要注意的是:

这里其实就是比对TO版本和FROM版本的差异,并把差异合并到TO的当前版本(head版本)中去。

注:如果要把分支所有的修改合并到主干上,FROM需要选择主干创建见分支时的版本号,TO选择分支最新版本(head版本)就行了。

如果FROM也选择主干head版本,TO也选择head版本,就会把所有分支与主干不同的差异覆盖到当前主干上来。造成主干的文件被分支覆盖。

合并当中出现:

no uncommited modified :表示当前版本还有没有提交的文件,如果不需要提交就选择revert.

working copy at a single version:表示当前目录没有从SVN服务器更新最新的版本。update下后在操作就行了。

很久没有写这么长的文章了,希望对大家有帮助。

     

05-02 17:30