Git前时代：使用CVS进行版本控制(4)

看来我们的朋友是真的喜欢粉红色，但好在他们编辑的是此文件的不同部分，所以很容易地合并此修改。跟 git pull 类似，只要运行 cvs update 命令，CVS 就可以为我们做合并操作，如下示：

$ cvs update
cvs update: Updating .
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into favorites.txt
M favorites.txt

此时查看 favorites.txt 文件内容的话，你会发现你的朋友对文件所做的更改已经包含进去了，你的修改也在里面。现在你可以自由的提交文件了，如下示：

$ cvs commit
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <-- favorites.txt
new revision: 1.4; previous revision: 1.3

最终的结果就跟在 Git 中运行 git pull --rebase 一样。你的修改是添加在你朋友的修改之后的，所以没有 “合并提交” 这操作。

某些时候，对同一文件的修改可能导致冲突。例如，如果你的朋友把 “green” 修改成 “olive”，同时你完全删除 “green”，就会出现冲突。CVS 早期的时候，正是这种情况导致人们担心 CVS 不安全，而 RCS 的悲观锁机制可以确保此情况永不会发生。但 CVS 提供了一个安全保障机制，可以确保不会自动的覆盖任何人的修改。因此，当运行 cvs update 的时候，你必须告诉 CVS 想要保留哪些修改才能继续下一步操作。CVS 会标记文件的所有变更，这跟 Git 检测到合并冲突时所做的方式一样，然后，你必须手工编辑文件，选择需要保留的变更进行合并。

这儿需要注意的有趣事情就是在进行提交之前必须修复并合并冲突。这是 CVS 集中式特性的另一个结果。而在 Git 里，在推送本地的提交内容之前，你都不用担心合并冲突问题。

标记与分支

由于 CVS 没有易于寻址的提交对象，因此对变更集合进行分组的唯一方法就是对于特定的工作目录状态打个标记。

创建一个标记是很容易的：

$ cvs tag VERSION_1_0
cvs tag: Tagging .
T favorites.txt

稍后，运行 cvs update 命令并把标签传输给 -r 标志就可以把文件恢复到此状态，如下示：

$ cvs update -r VERSION_1_0
cvs update: Updating .
U favorites.txt

因为你需要一个标记来回退到早期的工作目录状态，所以 CVS 鼓励创建大量的抢先标记。例如，在重大的重构之前，你可以创建一个 BEFORE_REFACTOR_01 标记，如果重构出错，就可以使用此标记回退。你如果想生成整个项目的差异文件的话，也可以使用标记。基本上，如今我们惯常使用提交的哈希值完成的事情都必须在 CVS 中提前计划，因为你必须首先有个标签才行。

可以在 CVS 中创建分支。分支只是一种特殊的标记，如下示：

$ cvs rtag -b TRY_EXPERIMENTAL_THING colors
cvs rtag: Tagging colors

这命令仅仅只是创建了分支（每个人都这样觉得吧），所以还需要使用 cvs update 命令来切换分支，如下示：

$ cvs update -r TRY_EXPERIMENTAL_THING

上面的命令就会把你的当前工作目录切换到新的分支，但《Pragmatic Version Control Using CVS》一书实际上是建议创建一个新的目录来房子你的新分支。估计，其作者发现在 CVS 里切换目录要比切换分支来得更简单吧。

此书也建议不要从现有分支创建分支，而只在主线分支（Git 中被叫做 master）上创建分支。一般来说，分支在 CVS 中主认为是 “高级” 技能。而在 Git 中，你几乎可以任性创建新分支，但 CVS 中要在真正需要的时候才能创建，比如发布项目。

稍后可以使用 cvs update 和 -j 标志将分支合并回主线：

$ cvs update -j TRY_EXPERIMENTAL_THING

感谢历史上的贡献者

（编辑：ASP站长网）