看完了上篇，我们对于多分支开发容易产生的问题应该有了一些基本的了解吧。事实上，通常，并行开发的版本管理面临以下几个典型的难题

 　　◆　如何保证新版本开发与BugFix同时进行?也就是要求修改过的BUG不能存在于新版本中题

 　　◆　如何保证两个新版本并行开发?可能的情况是两个完全不同的版本，或者一个是另外一个基础题

 　　◆　 如何保证版本的发布不受开发人员无意的代码检入影响? 

 　　不再拐弯抹角了，解决这三个难题的答案是使用分支（这里设计到一个著名的版本管理工具-ClearCase,分支正是其中的重要工具和概念）。

　　[OK，这里有个术语，就是分支。要理解分支必须同时理解其他的术语，比如说标签、视图。本文不打算详细的描述基础的概念，相关的概念可以参考ClearCase（一个强大的版本管理工具）的文档。]

   上面是一颗版本树，形象的记载了一个文件的版本变化情况。

　　◆其中1、2、3是不同的版本，

　　◆Main，Ver2.0就是分支。

　　◆Release1023和Ver2.0Begin则是标签，标签就像是打在代码版本上的标记。

　　◆视图就是由分支类型、标签名称、获取规则动态的决定的代码横截面。我可以建立Main分支的视图，在这个视图中我就看不到Ver2.0分支中的任何代码修改，我也可以建立Ver2.0分支的视图，在这个视图中我们可以看到Ver2.0分支的最新代码和未在Ver2.0分支中产生修改的Main分支中位于Ver2.0Begin标签处的代码。开发人员总是习惯工作于一个视图上。

       OK，那看看解决第一个问题的办法。

　　建立用于修改BUG的分支视图，在此视图上进行修改将在BugFix上修改的代码合并到主分支中，合并产生新的版本3，移动Ver2.0Begin标签到版本3，Ver2.0分支自动获取到修复BUG以后的代码，同时，主分支上的BUG也得到了修正如果此时代码已经在Ver2.0上发生了变化，则需要执行另外一个合并，将更改合并到Ver2.0中。但是幸运的是，大多数时候不会在BugFix之前修改Ver2.0的代码。
 
   这样做我们至少收获了几个附加的好处

　　◆　我们获得了从Main分支发布稳定版本的能力

　　◆　我们获得了从Ver2.0分支发布最新预览版的能力

　　◆　开发人员的检入检出不影响版本发布

　　◆　版本管理员可以对Main分支进行锁定等控制，防止其他人员越权或者意外的修改Main分支的代码