SVN 多分支管理

前言

    实际开发过程当中，会遇到多需求开发的同事维护线上版本bug。主版代码要一直和生产环境的程序保持一致，若是是小bug解决后提交部署没有问题，可是若是是比较难修复的bug，中间不能够在主版上提交，须要在分支上开发，测试经过后再提交主版。如何在修改bug过程当中在各个分支同步，今天作了一些研究，能够知足使用须要。

建立分支

建立一个开发新需求的分支，一个修改bug的分支。

开发过程

修改bug分支  

  在修改bug分支提交代码。

开发分支

开发分支同步修复的bug

 第一个选项：合并指定的版本，能够是从分支合并到主干，也能够是主干合并的版本，主要做用把分支的部份修改合并到主干上。

第二个选项：复兴分支，这里会把分支上全部的需改都合并到主干上。若是只想合并修改的一部分，并适合这项。

第三个选项：将主干上的修改合并到分支。

第四个选项：2个不一样的分支合并，但其实也能够是分支和主干的合并，只要from选择为主干就行。

我通常使用第一个选项。点击next后常常后提示两个错误。

第二个错误，查看资源历史记录，能够看到星标在4204，点击update后星标就会移动到4207。就能够继续合并了，具体原理如今还不知道。

选中在修改bug分支上的提交

合并结束后有冲突解决冲突，没有冲突能够将修改内容提交到当前分支

后记-中间遇到的疑问

    合并后和资源库对比，除了修改的java文件，老是有文件夹也提示和资源库有不一样的地方。

    通过查看同步过来的文件夹的文件属性发生变化，比较文件夹的SVN properties.

经过比较能够看到文件属性中多了一个4206的版本号，4206是修改分支提交时的版本号。

若是只提交修改的java文件，版本显示页面不会显示4206

若是连文件夹提交回提示在版本显示页面多了4206，可是我点击提交的时候提示了out of date 错误。我就有资源库的内容覆盖更新了没有再继续操做。

将修改的bug同步到主版的过程也相似。