三者定义
trunk:团队中大部分成员工作的主要仓库，前期大的团队的代码管理的主要控件，它的功能的侧重点是开发阶段的代码的管理的和集成，由于svn的冲突解决方式来进行代码冲突的处理，一般是最后提交的需要进行代码的处理，Xcode5以后的版本加强了对于svn的集成，所以现在Xcode可以更加方便的进行代码的提交和冲突解决，但是为了更好的进行分支和代码更新历史的管理，最好使用客户端进行辅助管理，比较推荐的Versions比较方便，不需要进行层次深入的更新操作
branches:分支既是从主干上衍生出来的代码副仓库，当然这个别称有待商榷，但是它的目的是显而易见的，就是为某些解决特定问题或者实现特殊功能的大牛们的专用仓库，他们会在开发的工程中，从团队的主干中分离出来，进行特殊的工作，而为了不让这些特殊的操作影响项目的进度和产品的上线，就从主干上复制一份当前的完整代码，交给某些人进行特殊功能的开发，如果在产品上线之前，这个分支的问题能够得到很好的解决的话，就会将分支的功能模块合并到主干上，为主干增加光采，当然分支的另一个主要功能是进行不同阶段的代码的备份
tag:标记是一个比较特殊的分支，存储的都是已经上线的产品。比如产品1.0上线之后，大家当然要继续埋头苦干为了2.0而加班加点，这个时候如果一旦发现1.0版本有很严重的bug，那么这个时候的操作就是在1.0的tag版本上创建另外一个分支，在这个分支里修改bug，同时主干的工作必须继续进行，尽快的进行产品bug的修复，之后将修改完的版本合并到主干中去，这样主干的工作没有收到影响，而且即时的解决了bug，并且以后的2.0版本也没有这个同样的bug了。
使用场景
场景一：客户想对产品做定制，但我们并不想修改原有svn中trunk的代码
场景二：正在开发产品下阶段的任务，但上阶段的工作发现问题
如何操作
以svn客户端最新版为例：
以场景二为例：项目某一阶段开发完成后，这个时候需要做一个tag，比如说tag_V1.0，然后基于这个tag发布一个新版本，trunk进入下阶段继续开发。但是很不幸发布的版本被检测出来了bug，有人会提议，把bug放到下阶段的任务中去。假设下阶段的任务才刚开始，用户可等不起.他们会认为一个小的bug解决要这么长时间,效率太低了。那么就需要基于tag_V1.0做一个branch，branch_bugfix_V1.0，基于这个branch进行bugfix，等到bugfix结束，做一个tag，tag名称假设为：tag_mf_V1.0,基于这个tag再发布一个版本。这样又没有影响trunk(主分支)的开发。然后，根据需要决定branch_bugfix_V1.0是否并入trunk。
