使用场景
假如你的项目的某个版本（例如1.0版本）已经完成开发、测试并已经上线了，接下来接到新的需求，新需求的开发需要修改多个文件中的代码，当需求已经开始开发一段时间的时候，突然接到用户或测试人员的反馈，项目中有个重大bug需要紧急修复，并且要求bug修复后要立即上线；此时应该怎么修复bug呢？
是在当前已经开发新需求的基础上进行修复吗？答案是否定的，原因是：如果是在已经开发新需求的基础上进行修复bug，那么新需求还没开发好，更没有测试，怎么立刻（或最可能快的）上线？另外如果新功能的开发和bug修复的代码都涉及到同一段代码冲突了怎么办 。
很显然不能在当前开发的代码基础上进行bug修复工作
那么就可以在当时完成的那个版本中进行bug修复，这样带来的好处是：
bug修复好之后可立即上线，不会因为新需求还没有完成或测试而延迟上线时间
bug修复是在原来上线的那个版本进行修复的，引起新bug的风险小，如果是在新需求的基础上修复bug, 那么新功能可能会带来新的bug
SVN仓库一般包含的目录结构：
truck (主干|主线|主分支)：是用来做主方向开发的，新功能的开发应放在主线中，当模块开发完成后，需要修改，就用branch
branches (分支)：分支开发和主线开发是可以同时进行的，也就是并行开发，分支通常用于修复bug时使用
tags (标记)：用于标记某个可用的版本，可以标记已经上线发布的版本，也可以标记正在测试的版本，通常是只读的
开发流程
1、主线版本开始，项目名称test
目录：
Repository/test/trunk
Repository/test/branches
Repository/test/tags
不要使用下面的形式，不利于开发人员和项目绑定形式的权限控制
Repository/trunk/test
Repository/branches/test
Repository/tags/test
2、主线开发完成1.0版本，使用Branch/Tag命令将主线标记一份到1.0版本目录中，交给生产环境部署；（注意，Branch/Tag命令不会直接拉取文件下来，需要update一次）
目录：Repository/test/tags/1.0
2、主线开始开发1.1版本，但突然生产环境1.0版本出现bug，此时，使用Branch/Tag命令将tag里面的1.0版本分支一份到branches目录
目录：Repository/branches/test/1.0
3、使用branch分支版本进行bug修复并提交代码到1.0分支，交给生产环境部署，部署没有问题之后，使用Branch/Tag命令将1.0分支标记一份到1.0.1目录；（当然也可以先tag到1.0.1，然后将1.0.1交给生产环境部署，但部署如果还是有bug，就需要重新处理bug，重新tag了）
目录：Repository/test/tags/1.0.1 （注意：该tag是从branch中的1.0版本tag过来的）
4、在Repositorytest/trunk目录上使用merge命令，将分支合并到主线，合并的时候可能有冲突，处理好即可。合并后需要提交，合并后分支可删除也可保留
5、有的时候可能同时有几个人处理多个bug，这样就会有多个分支，这个时候另外一个开发人员将bug修复并提交到了trunk，那么就应该及时从trunk合并merge一份到当前分支；
方法和branch合并到trunk一样，只是是在branches/1.0目录执行合并，Url to merge from的地址是trunk地址了
