查找了SVN的相关知识不管是园子里仍是百度都只有一些理论,而有实践教程的都是点到为止,并无一个完整的关于团队如何使用SVN协同工做的教程,所以写下该篇但愿能对你们起到一点帮助。
本教程面向有必定svn基础的,并且以前都是单人开发,对团队开发如何使用SVN并不了解,但急需了解的的同窗。
因为团队开发是若是没有正确的使用SVN常常出现A在作一个需求涉及到a,b项目,而B再作另外一个项目涉及到a,c项目。 而后A作完了直接提交了代码,可是并未通过测试。B的代码测试完毕而后提交准备投产,而后发现A已经提交了代码,因此他就获取了A的代码,编译后若是不询问A是否代码通过测试,可能直接投产了,而后投产出现了问题。或者知道了A的代码还未测试,必须等测试经过后才能投产。不然只能恢复到测试完的代码进行投产。最后甚至有可能就忘记提交了。
规定代码必须通过测试后才能提交,这必定程度上解决了这个问题,可是这就偏离了版本控制的初衷并且每次开发代码必须一次性开发完成,若开发中途发现问题,致使一部分代码须要重打,那么就不能很好的回滚。
如下操做都是使用VS的VisualSVN插件,其余插件使用方法都是差很少的,在文件资源管理器中使用方法原理是同样的。缓存
首先针对咱们的SVNTest1项目服务器
在项目右击菜单中将整个项目加入到SVN中svn
首选选择须要加入的根目录点击下一步工具
新项目选择新建仓库,若已经在SVN服务器建立目录接口就选择添加存在项目测试
选择SVN的路径插件
在svn中咱们建立的仓库下包含trunk,branches和tags三个文件夹,trunk为主线,branches为分支而tags则是标签
trunk:用于存放主线代码,咱们不能在这里进行开发
branches:用于并行开发使用,每一个需求或者bug修复都须要建立一个分支
tags:这里的代码不能编辑,只可读取,每隔标志性版本咱们能够在tags中建立一个标签,如V1.0正式版,那么当代码合并到trunk后能够建立一个标签,若是接下来开发v2.0版本,而忽然发现v1.0有个bug,就能够将次代码建立一个新分支用于修复bug,修复完成后能够合并到主线任务中并建立v1.1标签
咱们可使用2种结构开发咱们的项目,第一种是每一个项目文件夹下建立这三个目录,而后进行开发;第二种方式在根目录下就建立三个文件夹,而后在这三个文件夹下有多个项目。这里我用第一种方式,两种方式只是结构不一样,原理同样的版本控制
若是须要验证输入用户名和密码,而后点击导入,新项目就导入成功code
导入成功只是在咱们本地SVN缓存中导入成功,咱们必须提交到服务器中htm
咱们能够将bin和obj这些目录忽略掉,不然每次编译提交后他人更新都会有冲突,在VisualSVN插件提交默认已经忽略了这两个目录所以直接提交便可。
如今主线已经建立好了 ,若是咱们要进行开发或者修复bug,请不要在主线上面开发,咱们必须先建立分支,而后再分支上进行开发,这样就不会影响到主线的代码,当分支开发完成并测试经过后能够合并到主线,同时若分支没用便可删除。
在工具栏中有经常使用的按钮,方便咱们使用,若是使用其余SVN插件也是相似的,咱们也能够直接在项目右击进行操做
不知为什么在菜单中没有建立分支选项,咱们直接在工具栏中建立,在文件夹右击建立分支也是同样的
若是否选切换工做副本至新分支,那么建立完会自动切换,若是没有钩,那么咱们仍是在原来的主线,咱们暂时不勾选手动切换分支
建立完成因为咱们没有勾选自动切换,svn就提示了咱们手动切换,同时SVN服务器中也有了新的分支
默认只有主线,这里咱们选择切换到其余分支
如今咱们已经切换到新的v0.1的分支了,如今假设person2同窗须要对对该项目进行同步开发,所以咱们但愿每一个人能区分开来,咱们能够将项目根据人来区分,如
/Test/branches/person1/v0.1
,/Test/branches/person1/v0.1-bug1
,/Test/branches/person2/v0.1
等,也能够根据项目来区分,如如/Test/branches/v0.1/person1/xxx
,/Test/branches/v0.1/person1/fix-bug1,
/Test/branches/v0.1/person2`等。只要决定一个规范既可。
如今咱们约定以/Test/branches/v0.1/person1
的方式来存放,那么首先person1能够建立一个新的分支进行开发。
模拟person2同窗并行开发,因为B同窗须要获取全新的项目,所以须要首先从版本库中获取该项目
如今B同窗须要建立一个新的分支到person2目录
此时目录结构如图所示,为了不干扰项,我已从svn服务器删除了第一个建立的分支
如今person1和person2能够独立进行开发并提交代码到本身的分支上而不会影响主线,更不会影响其余人的开发了
person1添加了一个文件1.cs
person2添加了一个文件2.cs
咱们发现他们能够正常提交而无需更新,由于实际他们是在不一样的分支工做,固然不会产生影响
假设person1已经开发完成并经过测试须要将分支合并到主线
切换到主线
点击合并
到此为止已经将分支合并到咱们的主线,可是这里的主线只是咱们本地的主线(svn会将分支保存到不一样的目录,所以咱们本地不一样分支会存放在不一样的临时目录的,在svn文件夹下,不要手动去修改该目录)
将本地主线提交到服务器
咱们能够看到合并到主线后,咱们的解决方案管理器有些黄色的圆点表明修改,咱们看下svn服务器
发现咱们虽然提交了代码实际服务器主线还并无1.cs文件
提交成功后发现svn服务器主线已经有该文件
4. person2已经开发完成并经过测试须要将分支合并到主线
5. person2须要切换到主线
6. 切换完点击合并
会发先有冲突,由于person1已经提交了代码,而你本地的代码并非最新代码,因此合并以前先将主线代码合并到分支,而后分支解决冲突后提交到服务器分支。再从新切换到主线进行分支合并,此时完整的流程即走完
以上3个步骤忽略,不要直接切换主线,而是提交代码前先保证分支代码最新,首先将主线合并到分支
解决冲突后,便可提交代码
代码还未提交时SVN服务器person2目录实际尚未1.cs文件
提交代码后就有了
合并分支到主线
提交主线代码
因为person1并未获取person2的代码所以person1实际只有1.cs,而person2因为在person1提交的代码后更新了主线代码,所以perosn2有1.cs和2.cs
版本发布只针对trunk的目录进行发布
如今开发任务已经完成,咱们认为这个版本已经很成熟,咱们但愿把这个版本定为v1.0,咱们如今能够删除分支,同时将该版本打个标记
删除分支
直接删除无用分支便可
作v1.0的标记
标记其实就是一个分支,只不过tags文件夹应该设置为只读权限
切换到主线切出一个tags
如今咱们可能在开发2.*的版本了,忽然发现1.0的版本有bug
从tags/v1.0版本中切除一个分支修复bug
修复bug后作一个v1.1的tags,或者根据状况合并当trunk
修复bug后合并到trunk分支
至此整个团队开发生命周期就讲解完毕,接下来就是不断佚代的过程。
以上是我我的理解,若是看来此篇文章略有所学,请支持下,如如有误烦请指正。
PS: 第一次用vs code编写,仍是挺好用的(●ˇ∀ˇ●)
本文地址:http://www.javashuo.com/article/p-xoozwnym-br.html 做者博客:杰哥很忙 欢迎转载,请在明显位置给出出处及连接)