并行开发版本管理之路（二） --- 典型的版本管理难题

上一篇：并行开发版本管理之路（一） --- 版本管理危机

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

1.   如何保证新版本开发与 BugFix 同时进行 ? 也就是要求修改过的 BUG 不能存在于新版本中
2. 如何保证两个新版本并行开发 ? 可能的情况是两个完全不同的版本，或者一个是另外一个基础
3.   如何保证版本的发布不受开发人员无意的代码检入影响 ?

    

    

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

 

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

`
 

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

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

 

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

 

         

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

   这样做我们至少收获了几个附加的好处

1. 我们获得了从Main分支发布稳定版本的能力
2. 我们获得了从Ver2.0分支发布最新预览版的能力
3. 开发人员的检入检出不影响版本发布
4. 版本管理员可以对Main分支进行锁定等控制，防止其他人员越权或者意外的修改Main分支的代码

待续……

转载于:https://www.cnblogs.com/QuitGame/archive/2006/10/23/537744.html