svn分支管理的使用与经验

篇一

---

最近项目用上了svn分支管理，因为项目太过庞杂，版本迭代也过于频繁，致使多个版本的代码交杂在一起，难以维护，无法保证其中某个版本的稳定性。当然，我们也用过很土的办法，代码复制一份出来，但是，这个副本也需要加上新开发的功能。

所以，我们决定使用svn分支管理。当然，这有代价，svn版本管理对二进制文件不友好，可能文件分支合并时二进制文件会难以处理。（这里说的二进制文件，泛指所有非文本文件，比如说美术资源，策划文档）

 

svn分支简述

使用分支最主要的目的是，多个分支可以并行，相互不干扰，而且任何时候都可以合并。其次，容易保证主干的稳定性。

 

没有分支的时候，你的svn可能是这样的：

就一份代码存在主干（trunk），当然也不会有主干这个说法。开发完1.0，继续开发2.0，版本一个一个迭代。

 

有了分支后，你的svn可能就是这样的了：

主干用来存放稳定的代码，每个版本都会开一个分支，等版本完成后再合并到主干。版本一个一个迭代，但可以并行开发。

 

 

svn分支管理

接下来，简单讲解下 如何使用svn做分支管理。

 

第一步，建立主干分支目录结构

 

第二步，创建分支

在主干目录 trunk 右键，在svn菜单选择 Branch/tag...

步骤①是分支地址，这里直接以 /branches/1

步骤②是取trunk版本，HEAD revision表示最新版本，其他可通过 show log选择

执行 OK 后，到 branches 目录 svn update 就可以看到最新的分支了。

 

第三步，合并分支到主干

分支就是开发目录了，现在分支提交一个文件做测试。

然后，合并这个文件分支到主干。

现在到主干目录，右键svn菜单选 Merge...

 

这个是将分支或主干的修改合并到当前工作目录，继续如下。

接下来点完成，如果没冲突的话，分支文件就合到主干了。

 

但这里还要一个操作，就是在主干提交分支合过来的文件。

题外话，之所以要有这一步，除了对分支内容进一步修改，还可以同时合并多个分支。选择权交给用户。

另外，主干内容合到分支，也是使用 Merge 命令。

 

svn分支应用

根据项目的不同，实际上的分支架构也会不同。以我们项目为例，我们是做游戏的，项目过于庞杂，版本迭代非常频繁。在版本1.1还没完成时，我们可能就要开发2.0版本，这样，版本1.1和版本2.0就要并行开发。而且，我们对稳定性有非常高的要求。

 

为此，我们设计了这样的svn架构。

 

测试分支

为了保证主干稳定，我们加了测试分支（如 rel_1.1的测试分支为 rel1.1_test ）。测试分支1.1是在分支1.1开发结束后开的，等待测试修复bug完成后，就会把测试分支1.1合入主干及分支1.1。合并完成后，这个测试分支将会关闭。

 

多分支并行

因为项目需求较多，版本迭代繁杂，所以在版本1.1还没结束时，就开了版本2.0的分支。当分支2.0需要测试合并到主干时，就会从主干合并最新的文件到2.0测试分支，测试通过后，再合并到主干。

 

分支合并的时机

对我们而言，不同分支的最大区别是功能上线的时间点。我们根据上线周期划分功能，拆分到不同分支。因为开发需求多，迭代过于频繁，所以靠后的分支对比之前的分支通常只是多了某些新功能。这样，分支的出现，避免了未开发完成的功能影响了已开发完的功能，导致当前版本的不稳定。所以，合并分支的时机就是这个分支的功能要不要上线。

 

这样，主干永远是稳定的，也只有经过测试的内容，才会合入主干。同时，多个版本也可以并行。

 

参考：http://blog.csdn.NET/mycwq/article/details/51793847

 

 

 

篇二

---

SVN分支管理策略个人见解

本篇目录

• 前言

• SVN分支管理策略

• VisualSVN Server

• TortoiseSVN客户端

  • Repository的创建

  • Check out

  • trunk创建新项目MyProject

  • trunk更新提交更新，迭代版本创建Tag V1.0

  • 基于Tag的Hotfix Branch

  • Hotfix Branch改动Marge(合并)到trunk中同时创Tag_V1.1进行发布

  • 定制化分支Customize branch

• 总结

前言

使用svn做为源码管理工具已有几年，但一直都只是使用到了trunk。最近项目中发版本每次都会将一个版本的文件拷贝打包为rar压缩文件，下个版本迭代则重新在svn服务端创建新的Repository用于管理。显然这tag版本脱离了svn的管理，日志记录也会发生断层。

于是最近就查阅了一些文章，结合实际对 trunk、tags、branches 进行体验操作，有点收获，怕以后忘了，故做此记录。

 

SVN分支管理策略

其中

Trunk：主开发分支，所有最新的代码都在这里。

Tags：一个里程碑版本，一般都可保证直接上线(名字：”V1.0”,”V1.1”,”V2.1”,”School_V1.0”,”School_V1.1”…)，用于存放发布的版本。

Hotfix branch：修正bug的分支(名字：”hotfix_V1.x”,” School_hotfix_V1.x”, “School_hotfix_V1.x”)，从需要修复的tag拉出分支，用于解决已上线版本的bug。

Customize branch：定制化需求的开发分支(名字：”School_Develop”…)，用于定制化需求开发一个版本。

VisualSVN Server

服务端采用VisualSVN Server是免费的，而客户端VisualSvn是收费的，可使用免费AnkhSvn替代集成至Visual Studio使用。VisualSVN Server的下载地址：https://www.visualsvn.com/server/download/，VisualSVN Server的安装使用网上有很多文章，此处不做描述。

TortoiseSVN客户端

Repository的创建

Check out

首先Checkout在服务端repository创建的Test，默认创建了三个空文件夹。

trunk创建新项目MyProject

trunk更新提交更新，迭代版本创建Tag V1.0

提交迭代版本更新。

基于trunk中最新版本创建Tag_V1.0。在/trunk/MyProject目录上右键，依次选择"TortoiseSVN" -> "Branch/tag..."，在弹出窗口的"To path"中填入tag的地址。

提交后在文件夹更新后会在Test\tags文件夹下出现MyPro_V1.0文件夹，tags目录下的MyPro_V1.0文件夹就是以trunk中指定的版本拷贝的副本做为版本V1.0进行的封存。

基于Tag的Hotfix Branch

当版本V1.0发布上线后，出现线上bug后需要修复，则以Tag中MyPro_V1.0创建Hotfix Branch(步骤和创建Tag类似)，在Hotfix的分支中修复问题。修复完成后需要将此次的改动Marge(合并)到trunk中同时创Tag_V1.1进行发布。

提交后在文件夹更新后会在Test\branches文件夹下出现bugfix_by_account文件夹，在此基础上修复问题并提交。

在/branches/bugfix_by_account目录上右键，依次选择"TortoiseSVN" ->"Revision graph"，在弹出的窗口中可以看到版本分支图。

 

Hotfix Branch改动Marge(合并)到trunk中同时创Tag_V1.1进行发布

在/trunk/MyProject目录上右键，依次选择"TortoiseSVN" ->"Merge..."，

点Next出现如下窗口，

如果trunk中的版本修改过的文件与Hotfix分支中的修改不重合则不会产生冲突。下图是trunk进行过版本提交，与Hotfix分支中的修改产生冲突。

点击 Edit Confict解决冲突。

冲突处理完后点击Resolved，冲突解决完成本地trunk中已包含Hotfix分支的内容，合并后需要提交至svn服务器。

Hotfix分支修复完成后创建Tag_V1.1与之前trunk创建Tag_V1.0类似。

完成以上动作后的版本分支图如下。

定制化分支Customize branch

定制化分支使用的方式和之前创建branch方式类似，在此不做赘述。

总结

合并发生在本地working copy，只要你不提交就不会影响到repository。

合并前一定要先update、commit，保证不会out of day，并将本地的修改保存到repository。

使用svn创建的分支都会在指定的文件夹中创建副本，如果是在不同的分支文件夹中开发时候需要重新对项目配置（eg：IIS外部主机），也可在trunk中切换分支则不用修改配置，但是svn服务端需要保持可连接状态。

最后说一句用过git之后，再也不想用其它[源代码]管理器。

 

转载自：

https://www.cnblogs.com/ddrsql/p/5909683.html