前言

查找了SVN的相关知识无论是园子里还是百度都只有一些理论，而有实践教程的都是点到为止，并没有一个完整的关于团队如何使用SVN协同工作的教程，因此写下该篇希望能对大家起到一点帮助。

面向人群

本教程面向有一定svn基础的，而且之前都是单人开发，对团队开发如何使用SVN并不了解，但急需了解的的同学。

背景

由于团队开发是如果没有正确的使用SVN经常出现A在做一个需求涉及到a,b项目，而B再做另一个项目涉及到a,c项目。
然后A做完了直接提交了代码，但是并未经过测试。B的代码测试完毕然后提交准备投产，然后发现A已经提交了代码，所以他就获取了A的代码，编译后如果不询问A是否代码经过测试，可能直接投产了，然后投产出现了问题。或者知道了A的代码还未测试，必须等测试通过后才能投产。否则只能恢复到测试完的代码进行投产。最后甚至有可能就忘记提交了。

解决方案

规定代码必须经过测试后才能提交，这一定程度上解决了这个问题，但是这就偏离了版本控制的初衷而且每次开发代码必须一次性开发完成，若开发中途发现问题，导致一部分代码需要重打，那么就不能很好的回滚。

团队开发生命周期

创建新项目

以下操作都是使用VS的VisualSVN插件，其他插件使用方法都是差不多的，在文件资源管理器中使用方法原理是一样的。

首先针对我们的SVNTest1项目

1. 在项目右击菜单中将整个项目加入到SVN中

   

2. 首选选择需要加入的根目录点击下一步

   

3. 新项目选择新建仓库,若已经在SVN服务器创建目录接口就选择添加存在项目

   

4. 选择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种结构开发我们的项目，第一种是每个项目文件夹下创建这三个目录，然后进行开发；第二种方式在根目录下就创建三个文件夹，然后在这三个文件夹下有多个项目。这里我用第一种方式，两种方式只是结构不同，原理一样的

5. 如果需要验证输入用户名和密码,然后点击导入,新项目就导入成功

   
   
   

6. 导入成功只是在我们本地SVN缓存中导入成功，我们必须提交到服务器中

   
   
   

7. 我们可以将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`等。只要决定一个规范既可。

1. 现在我们约定以/Test/branches/v0.1/person1的方式来存放，那么首先person1可以创建一个新的分支进行开发。

   

2. 模拟person2同学并行开发，由于B同学需要获取全新的项目，因此需要首先从版本库中获取该项目

   
   
   

   现在B同学需要创建一个新的分支到person2目录

   

   此时目录结构如图所示,为了避免干扰项，我已从svn服务器删除了第一个创建的分支

   

3. 现在person1和person2可以独立进行开发并提交代码到自己的分支上而不会影响主线，更不会影响其他人的开发了

   • person1添加了一个文件1.cs
     
     
     

   • person2添加了一个文件2.cs

   
   
   

   我们发现他们可以正常提交而无需更新,因为实际他们是在不同的分支工作，当然不会产生影响

合并代码

假设person1已经开发完成并通过测试需要将分支合并到主线

1. 切换到主线

   

2. 点击合并

   
   
   
   

   到此为止已经将分支合并到我们的主线，但是这里的主线只是我们本地的主线(svn会将分支保存到不同的目录，因此我们本地不同分支会存放在不同的临时目录的，在svn文件夹下，不要手动去修改该目录)

   

3. 将本地主线提交到服务器

   

   我们可以看到合并到主线后，我们的解决方案管理器有些黄色的圆点代表修改，我们看下svn服务器

   

   发现我们虽然提交了代码实际服务器主线还并没有1.cs文件

   
   
   

   提交成功后发现svn服务器主线已经有该文件

   4. person2已经开发完成并通过测试需要将分支合并到主线

   5. person2需要切换到主线

   

   6. 切换完点击合并

   
   
   
   

   会发先有冲突,因为person1已经提交了代码，而你本地的代码并不是最新代码,所以合并之前先将主线代码合并到分支，然后分支解决冲突后提交到服务器分支。再重新切换到主线进行分支合并，此时完整的流程即走完

4. 以上3个步骤忽略，不要直接切换主线，而是提交代码前先保证分支代码最新，首先将主线合并到分支

   
   
   

5. 解决冲突后，即可提交代码

   

   代码还未提交时SVN服务器person2目录实际还没有1.cs文件

   

   提交代码后就有了

   

6. 合并分支到主线

   
   
   
   

7. 提交主线代码

   

   由于person1并未获取person2的代码因此person1实际只有1.cs,而person2由于在person1提交的代码后更新了主线代码，因此perosn2有1.cs和2.cs

正式版本发布

版本发布只针对trunk的目录进行发布
现在开发任务已经完成，我们认为这个版本已经很成熟，我们希望把这个版本定为v1.0,我们现在可以删除分支，同时将该版本打个标记

1. 删除分支

   直接删除无用分支即可
   

2. 做v1.0的标记

   标记其实就是一个分支，只不过tags文件夹应该设置为只读权限

   

   切换到主线切出一个tags

   
   

bug修复

现在我们可能在开发2.*的版本了，突然发现1.0的版本有bug

1. 从tags/v1.0版本中切除一个分支修复bug

   
   

2. 修复bug后做一个v1.1的tags，或者根据情况合并当trunk

   
   

3. 修复bug后合并到trunk分支

   
   
   

结束语

至此整个团队开发生命周期就讲解完毕，接下来就是不断佚代的过程。
以上是我个人理解，如果看来此篇文章略有所学，请支持下，如若有误烦请指正。

PS: 第一次用vs code编写,还是挺好用的(●ˇ∀ˇ●)