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 主干的代码合并到分支
和场景1的区别就是:
a.选择合并方式的时候,选择第一个选项:Merge a range of revisions。
b.看下面的图。
c.然后对分支进行提交。
场景3 冲突解决
再次切换到分支代码,将分支代码更改
然后切换到主干代码trunk,项目右键-team-合并,选择第二项,分支合并到主干,next。就会出现如下图结果,将冲突解决完后,右键-》标记为解决冲突
冲突的代码就解决完了。
最后附带merge input 合并类型截图