myeclipse插件—SVN分支与合并详解【图】

来源:互联网 发布:淘宝订单不能评价 编辑:程序博客网 时间:2024/05/01 12:48

svn作为版本控制软件被广泛用于众多公司的开发团队中,最多的场景就是一个项目上传svn后,一个组内的小伙伴在上边提交和更新代码以及解决冲突,其实这只是发挥了svn的很小的一部分功能。

先稍微介绍一下svn的两种开发和发布的规范:

一 主干修改,分支发布

代码都在trunk上修改,需要发布的时候,从主干上拉出一个版本,如果该版本发现BUG则继续从该分支上修改,并将修改合并到主干上。

二 主干发布,分支修改

任何修改都不能在主干上直接进行,开发新功能,从主干上分支出一个版本,进行开发,发开测试完毕后,在合并到主干上。

个人比较推崇第二种,其优势在于各个分支独立进行,互不干扰,可以使不同开发周期的应用在同一个项目中开发进行。对于同一个应用,a组人开发完毕,b组人只做了一半,这个时候,对于主干修改,分支发布,这样是根本不能发布出去的,而对于主干发布,分支修改,只需要把a组的修改合并回主干就可以发布出去了,b组开发的根本不受影响。


下面介绍一下分支,合并的应用场景,并针对场景进行一个小栗子。

场景1: 采用主干发布,分支修改的规范后,项目要新开发一个功能,这时候我拉开了一个分支,开发完毕后要分支代码合并回主干。

场景2:我在分支的开发过程中,主干被其他的项目组进行较大的改动,为了避免在“正确”(trunk)的道路上走歪了,也为了避免最终合并代码的时候,太过麻烦,我需要将主干的代码合并到分支上来

场景3:对于同一个文件,同一个方法内的代码合并的时候冲突问题解决


案例:事先准备工作,我需要在svn创建一个项目test,并创建一个分支test2.0 如图,项目右键--Team-分支


然后刷新一下svn仓库,对比看一下trunk主干和branches分支里面多了一个2.0的test



场景1 分支代码合并回主干。 

项目右键-team-先切换到分支代码,然后将分支代码进行改动,然后在切换回主干代码,进行合并操作,如图




然后将分支的修改代码提交svn一下,然后同样切换回主干trunk代码,准备合并。

切换回主干代码后,分支代码修改的地方,主干代码不受影响,还是老样子。

右键team-选择合并,然后选择第二个选项:分支合并到主干



这时候,你就会看到分支的代码被合并到主干上来了,然后提交svn就可以了



场景2:就不介绍了,唯一的区别就是选择合并方式的时候,选择第一个选项就可以了

场景3:冲突解决

再次切换到分支代码,将分支代码更改



然后切换到主干代码trunk,项目右键-team-合并,选择第二项,分支合并到主干,next。就会出现如下图结果,将冲突解决完后,右键-》标记为解决冲突





冲突的代码就解决完了。


最后附带merge input 合并类型截图


2 0
原创粉丝点击