svn切分支与分支合并

SVN的标准目录结构：trunk、branch、tags

目录在SVN中并没有特别的意义，这三个目录反映了软件开发的通常模式

trunk：主干，是日常开发进行的地方

branches：分支，一些阶段性的release版本，这些版本是可以继续进行开发和维护的

tags：阶段性的发布版本，存放到这里

现在来看一下日常开发的流程：

假说现在有一个游戏项目，项目经理说今天项目要上线了，我们要把代码打包部署，然后供玩家使用，玩家正在玩的时候我们还是要继续进行新需求的开发吧，加入我们不使用svn的目录结构，我们继续在原有的代码上开发，又过了两天，有玩家反馈说游戏有bug，根据玩家提供的bug信息，我们修复了bug，修复了bug后准备在下一次维护服务器的时候将修复bug后的代码部署到服务器上。

现在问题来了，我们还没准备好将正在开发的新功能上线，但是和新功能相关的代码已经提到svn了，bug改完也提到svn了，这个时候打包就会将新功能打到包里，这肯定是不允许的。那怎么解决呢？

有如下两个办法

1、上线时，每个人从svn上迁出一份代码，然后保存到自己的本地，这样出现bug的时候定位责任人，责任人修改bug的时候在自己的本地修改完打包部署，这样真的可以解决吗？如果出现了10多个bug(完全有可能)，这10多个bug分别出在不同的责任人身上，这些人修复完bug后怎么将代码合并到一起？所以这个解决方案pass

2、上线一个版本后，新建一个svn服务器，想到这还敢往下想吗？这建议和项目经理提了估计都能把他气死

下面我们来看看使用svn的标准目录结构是怎么处理的

项目上线后，将上线时的代码切出一个分支branch，然后在主干继续进行新需求的开发，当上线的项目出现bug时，开发人员在分支上修复bug（分支的功能和svn是一样的），修复完bug后将代码打包重新部署，然后将代码和并到主干trunk上，当项目线上运行一段时间已经很稳定时，将项目切出一个tags，tags一般是只读的。这样就比较好的解决了新需求开发与bug修复的矛盾

开始介绍在svn上如何切出分支，如何将分支的代码合并到主干上

本文只介绍eclipse中的svn插件是如何切出分支和合并代码的

在trunk目录上点击Team-->分支/标记

会出现如下图所示的对话框，在到URL下的输入框中输入本次切出的分支的名称(注意目录结构，branches路径后的是切出分支的名称)

切出分支后在eclipse的branches上点击  Team-->与资源库同步就可以找到刚才我们切出的项目了

来看一下这是trunk中其中一个类的代码

现在切换到branches下 Team-->切换

切换成功后显示如下：

在branches上修改代码，然后提交到svn，一定要提交到svn，否则无法合并，提交到svn后将项目切换到主干，点击 Team -->合并

Reintegrate a branch：将分支上修复的bug同步到主干上，同步时会有很多种情况

1、主干上未做修改，分支上做了修改

2、主干上做了修改，分支上也做了修改

3、分支上增加了文件

下面会依次讲解着四种情况

Merge a range of revisions ：在主干上进行了修改，将这个修改同步到分支上，这个操作可以防止分支上的代码和主干上出现严重的冲突，但是要保证主干的上代码别影响线上的功能，如果不能保证就不要进行这个操作

点击next后出现如下界面，注意你现在是在主干上，而这个路径是分支上你修改的那个类文件的路径(因为是修复bug，很少会出现修改大量的类的情况，所有建议一个类一个类的合并到主干上)

之后一路点击next就可以了，合并之后在分支上修改的代码就同步到主干上了，这个时候主干上的这个类的状态是修改状态，要将这个类同步到svn才算是最终完成

主干上做了修改分支上也做了修改同步后的结果就是出现冲突文件，按照正常的解决冲突的办法来解决就可以了

如果是在branches上新增了文件，那么上面的路径就改成文件的上一级目录

主干同步到分支是类似的，主干上做的修改先提交到svn，然后切换到branches，合并时路径指向主干上被修改文件的路径然后一路next就可以了