CVS版本控制心得

撰写人 金珉

经过自己一年多CVS多版本切换合并的实战体会，现整理出个人目前阶段的最佳CVS版本控制方案，与大家交流。

1. 生成新的CVS项目

之后就是一个个next。

2. 新建开发分支（此步可跳过）

新建cvs项目后就立刻对于Head建立一个开发分支，虽然目前只需要一个分支。原因是我把Head定位为里程碑，Head上提交的新版本都是一个个已完成的可提交的版本。

给分支起名字，Version Name用于版本合并，会自动命名，建议不要修改，不然以后合并分支时容易分不清楚。

分支建立后，开发环境全部切换到此分支上。

这里记得点选刷新，不然看不到新加的分支。

选中正确的分支后点选确认即可切换到分支上。

3. 合并开发分支（如2跳过此步也跳过）

当开发验收通过后，先切换回Head，再做合并。

这里两个框，是从前者合并到后者，选择分支时，会自动带出建立分支时的Version Name，确认即进行两者的比较，产生下图情况。

因为Head没有进行过开发提交，所以只需要对于整个项目进行Merge。Merge后是不会直接提交到CVS上，还需再进行手动提交。

此时Head上为可正式提交使用的版本。

4. 多分支建立

因为版本大规模升级、功能增加、功能完善等需求，所以往往需要维护与开发一同进行，需要多版本并存，这时为了便于管理，应建立两大分支，一为Release版，一为Beta版，前者用于日常维护以及正式版本提交，后者用于新功能开发，建立过程不重复。

5. Release版与Beta版分支合并

当一个大更新验收通过后，这时就需要合并分支，如果冲突量很大的话，那合并后势必需要进行再一次测试，以保证程序的正确性、可靠性，所以往往是把Release版合并到Beta版上。

先切换到Beta版分支。

前者选Branch，后者选Tag。后者为建立当前分支时一同产生的Version Name。

正常情况下会出现上图的情况。

蓝色箭头带＋符号的为新增，因为目标分支上没有此文件，所以无版本号对比。

蓝色箭头不带＋符号的为有源头版本有提交新版本，源头版本号与目标版本号有对比，前者是目标版本号，后者是源头版本号。版本号的规则是每经过一个节点分叉就会增加两个数字，并永远是偶数个数字，例如：Head的版本号永远是1.A，对于Head建立分支

Release_0001、Beta_0001，那如果Release_0001有提交新版本，就会变成1.A.B.C，如果Beta_0001有提交新版本就是1.A.D.E。在合并时往往可直接看版本号来进行大部分的合并工作。

红色箭头不带＋符号的是指源头与目标都有提交过新版本，这时就需要对比两边版本，将两者整合在一起。

有时在合并分支时也会产生一些特殊情况。如下

红色箭头带＋符号的是指全文件冲突，看到这个符号时你可能会很头疼，但注意看版本号，版本号是一致的，说明源头与目标没有提交过新版本，这时只需要进行如果两种操作之一即可。

源头覆盖目标文件。

标记目标文件为最新版本。

看到红色箭头不带＋符号，乍看以为是两边冲突，但对比版本号能发现目标版本号的6个数字和源头版本号的前6个数字一模一样，说明目标文件未提交过新版本，源头文件有提交过新版本。这时只需要源头覆盖目标文件即可。 合并后记得手动提交。

当合并后的Beta_0001测试完成可提交正式使用时，将Beta_0001合并到Head上做为一个里程碑，提交之后再对Head进行分支建立Release_0002、Beta_0002，之后就如此重复下去。

6. 一些特殊处理

有时会有这种的需求：维护与大更新并行的时候，有小功能小模块需要处理，并且比大更新提前发布。

这时我的处理方式是对于Release_xxxx建立分支，比如Release_xxxx_Beta_xxx，新功能验收完成后前者合并到后者上，测试通过后再合并回Release_xxxx上，之所以再合并回Release_xxxx上是为了减少维护人员经常切换版本导致分支错误、分支不一致的概率。