大家都知道，SVN是很多公司管理代码的版本控制工具，当分支越来越多，版本迭代越来越频繁的时候，经常会出现代码冲突的头疼事儿，这里讲一下鲨鱼遇到过关于代码版本控制的一些事，最后做个小例子，看图描述。
为什么要用主干，分支的开发方式呢？
我认为使用主干，分支的开发模式，有两个好处。
一是各需求的开发环境独立，不相互影响，对于项目经理规划版本，将版本功能粒度化，分派开发工作，主干的主功能开发和一些临时紧急缺陷需要修复上线不受影响。
二是代码通过合并的方式可以减少代码相互覆盖，这里为什么说是减少而不是说避免呢，因为实践中总是告诉我们现实并不总是那么理想的。
举个例子，我曾经任职的一家公司，代码是导出差异包，加上配置文档提交给测试去覆盖主干代码来打包测试的。有几十号开发人员，每个版本十来个需求，每个需求提一个差异包过来，总共就十来个压缩包，一一解压覆盖到工程中，对着配置文档一一添加或修改配置，然后编译打包部署测试。这过程中，如果有不同的压缩包里面都存在修改了相同一个文件，就会被后面解压覆盖掉前面的文件。这两个开发开发的过程中并不知道其他人也要修改这个文件，所以问题就来了。覆盖了怎么办，退回去让他们一起协商提供一个最新的文件么，这个过程中，其他的需求怎么办，重新覆盖打包么？这是一段很坑爹的经历，真的是很奇葩，但是确实存在着。
后来实在受不了了，开始改变这种开发方式，采取主干，分支的开发方式。以后就不用打包人员去根据配置文档配置，覆盖代码了。每个需求提交一个开发分支过来，将开发分支合并到测试分支进行测试。合并并不是覆盖，svn很智能的识别哪些文件是否存在冲突，如果有冲突会弹出冲突框进行文件对比来解决冲突。如果没有改动过的代码，是不会进行覆盖的，效率就提上来了，而且能看到某个开发修改了哪个文件，遇到问题可以找到提交改代码的开发进行处理。
还有曾任职的一家公司，是使用PHP的，开发人员很干脆的直接在服务器上正在运行的主干代码上vim。修改马上生效确实方便，直接给测试去测。但是这种情况有两个开发同时在上面开发需求就够呛了。一是A根据它的需求改了a.php代码，B又在同一个文件a.php上面相同的位置根据它的需求改了。都不知道对方的情况，瞎了。二是A的需求测试通过后，需要等B的需求也同样测试通过才能上线，还不能回滚，版本控制功能等于摆设。
我觉得比较正能量的是曾任职的一家公司，是用git的，也是主干分支的开发方式，是严格按照版本规划上线的，一不会上线前拆代码，二不会同时进行两个版本的开发，本身就是自研的产品，没有那么多后面叽叽歪歪的需求要求，每个开发负责一个版本的一个小功能，一个分支。开发完后集成到主干自测，最后自测通过后，等各开发各自的功能都完成后一一集成，版本开发完成后，提供主干一个版本号RC1，测试人员根据版本号检出代码打包部署测试，测试完一轮后提交bug报告，bug修复后，提供第二轮测试版本号RC2，测试人员进行第二轮测试。测试通过后测试人员将RC2的包部署到正式环境。
SVN 操作小实践：设定A开发直接在trunk上开发，B开发在branch上开发。
一，初始化trunk
a.php
b.php
二：从主干trunk上迁出开发分支branch_b1,将branch_b1检下来导入工程进行开发
场景一：A，B各自新增不同文件，开发完成后，branch_b1合并到trunk
主干上新增c.php，分支上新增d.php
合并结果：正常！ 在主干上，将分支上的差异作用到主干工作副本。
提交trunk代码，上线发布V1
【上载后，branch_b1 中并没有主干新增的代码c.php 一般情况下，分支代码上线后，B需要重新迁分支开发】
场景二：A，B同时修改a.php，但是修改位置不同，如A修改方法a1(),B重新迁分支branch_b2，新增方法a2().
trunk与branch_b2修改分别如：
将branch_b2合并到trunk：
合并结果：正常！没有冲突，trunk和branch_b2的修改都更新到了trunk工作副本。妥妥的！
提交trunk代码，上线发布V2
场景三：上载后，如果B不重新迁分支开发，继续使用branch_b2，且不把主干代码合并到开发分支 则branch_b2开发分支中并没有方法a1修改的内容，如果这个版本中，B在分支上大量修改方法a1，且多处引用a1，悲剧发生。B修改如下：
branch_b2开发完毕，合并到trunk
合并过程并没有提示冲突，B很开心，下班了。其实结果是错误的！！
合并结果：错误！！！ branch_b2修改的内容更新到了trunk工作副本，但是很明显，合并后出现问题了。branch_b2大量修改了旧代码，而不知道a1方法其实已经在上个版本已经被修改了。
场景四：假如上载后，如果B反向合并，将trunk上的代码反向合并到branch_b2，使开发分支与trunk同步，则会怎样呢？
1.先将trunk本地副本全部删除，update线上版本下来。
2.branch_b2 合并trunk
手动解决冲突
解决冲突，合并后，branch_b2会发现，a1方法被修改了。这时候本地可以提前发现问题，重新修改branch_b2使之兼容主干。
修改a2方法，如
准备提测上线了，重新合并到trunk。
合并结果：正常！ 没有冲突，合并妥妥的，结果也正确！但是建议上线后重新迁分支做新需求的开发，如果该分支在当前版本无法上线，那在trunk提交后，必须将开发分支与trunk同步，不然会走到越来越远，到最后上线前合并会出现很多无法避免的错误。