SVN 多分支管理

2019独角兽企业重金招聘Python工程师标准>>>

前言

    实际开发过程中，会遇到多需求开发的同事维护线上版本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同步到主版的过程也类似。

 

 

转载于:https://my.oschina.net/u/3714931/blog/1559759