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 合并类型截图
- myeclipse插件—SVN分支与合并详解【图】
- myeclipse插件—SVN分支与合并详解【图】
- myeclipse svn 分支合并
- SVN的分支与合并详解
- SVN的分支与合并功能详解
- SVN的分支与合并功能详解
- SVN分支与合并
- SVN分支与合并
- SVN分支与合并
- SVN分支与合并
- SVN分支与合并
- svn 合并与分支
- svn分支与合并
- SVN分支与合并
- SVN分支与合并
- SVN分支与合并
- SVN分支与合并
- SVN分支与合并
- JS组件系列——两种bootstrap multiselect组件大比拼
- eclipse安装插件提示 is not a valid repository location
- 【数据结构】树状数组模板--CODE[VS] 1080线段树练习and1081线段树练习2
- centos7 yum 方式安装nginx
- 读取xml文件
- myeclipse插件—SVN分支与合并详解【图】
- flex 布局下关于容器内成员 flex属性的理解
- Android 沉浸式statusbar (5.0以上无阴影,statusbar背景全透明)
- 译码器的应用
- [noip2008tg] 笨小猴
- iOS 线程队列
- 监听器
- js悬浮对联(随页面滚动而滚动)
- c,c++中调用shell脚本并保存shell的执行结果