SVN打分支,分支合并操作

这篇博客写了个标题就一直放在这了,最近忙完了手头的工作,有时间把这篇文章写完.

以前的项目没有太多需求,只在主干进行迭代开发,随着需求的日渐增多,不得不进行多版本并行开发.以前一直对分支合并敬而远之,怕开发中出现大问题给整个团队挖坑,但是事实证明,对一个知识不了解用起来还真有不少问题,真应了那句”书到用时方恨少”.言归正传,下边说说在开发中遇到的一些问题,顺便说说我们的解决办法,供大家参考.

假设以下场景,项目现在正在开发1.0版本,并且有bug待修复,而我们勤快的产品经理已经写好了1.1版本的需求,并且要求尽快开发完上线,那么我们就不可能等1.0版本修复完bug再进行开发1.1版本,这时候我们需要创建1.1版本的branch,并且在branch上进行新功能的开发,这时候可以继续在1.0上进行bug的修复.(我们这里暂且将1.0版本作为trunk)

好了,发现合并中蛋疼的问题了,那么我们想办法解决,既然一周代码改动量太大,那么我们每天都进行合并操作,这样虽然冲突的文件减少了,但是每天合并是很麻烦的事情.

上边说道暂且将1.0版本作为主干,其实这样的做法是不正确的,1.0版本也是我们的一个分支,我们的主干应该叫做trunk,像下图这样

我们要先将1.0的代码合并到trunk,这时trunk代码就保持了1.0版本的同步,然后再将trunk代码合并到1.1版本,也就把对bug的修复同步到了新版本中.

这个过程我们始终要保证代码的合并是单向的,不可逆的,即最低版本1.0合并到主干,主干再合并到高版本1.1,主干实际上并不做任何代码的开发工作,只起到一个桥接的作用,这样做的好处是,我们可以一次性地将1.0的代码全部合并到trunk(不用担心冲突的问题,因为现在的trunk不做任何代码的修改),然后我们将trunk的代码合并到1.1,这其中也会引起冲突的问题,因为毕竟两个版本的开发人员不知道对方改动了什么代码.我们采用的解决办法是不用ide自带的工具进行合并,直接用Beyond Compare文件合并工具进行手动合并,因为trunk代码不做修改,所以提交记录很一目了然,我们可以对比trunk上的提交记录来知道增加,修改,删除了哪写文件,从而把它们同步到1.1版本中.说道这里大家可能会说,那如果修改了同一个文件怎么判断哪边是正确的呢,是的没错,这的确是一个问题,因为不论是系统工具还是文件合并工具,它们不可能知道哪些代码是有用,哪些代码是无用的,这里只能靠我们自己多写注释来解决了,比如这样标记(modified by zhangsan 1.0 on 16/12/08 1.0版本增加这段代码修改XXbug),这样我们就知道了这是1.0版本为修复某个bug而添加的代码,在1.1中要保留,否则可能会在合并中被误删除…

好了,写了这么多,最后总结几点
1.严格按照trunk,branch结构来进行项目管理
2.trunk代码不做修改,只作比对的桥接作用
3.保证代码单向合并规则(由低到高),不可逆向
4.大量动代码写清注释,必要的时候及时与团队小伙伴进行沟通,避免合并出错引起不必要的麻烦
5.正确使用Beyond Compare工具