GitHub 网站发布于 2008 年。如果你的软件工程师职业生涯跟我一样，也是晚于此时间的话，Git 可能是你用过的唯一版本控制软件。虽然其陡峭的学习曲线和不直观地用户界面时常会遭人抱怨，但不可否认的是，Git 已经成为学习版本控制的每个人的选择。Stack Overflow 2015 年进行的开发者调查显示，69.3% 的被调查者在使用 Git，几乎是排名第二的 Subversion 版本控制系统使用者数量的两倍。 1 2015 年之后，也许是因为 Git 太受欢迎了，大家对此话题不再感兴趣，所以 Stack Overflow 停止了关于开发人员使用的版本控制系统的问卷调查。
GitHub 的发布时间距离 Git 自身发布时间很近。2005 年，Linus Torvalds 发布了 Git 的首个版本。现在的年经一代开发者可能很难想象“版本控制软件”一词所代表的世界并不仅仅只有 Git，虽然这样的世界诞生的时间并不长。除了 Git 外，还有很多可供选择。那时，开源开发者较喜欢 Subversion，企业和视频游戏公司使用 Perforce （到如今有些仍在用），而 Linux 内核项目依赖于名为 BitKeeper 的版本控制系统。
其中一些系统，特别是 BitKeeper，会让年经一代的 Git 用户感觉很熟悉，上手也很快，但大多数相差很大。除了 BitKeeper，Git 之前的版本控制系统都是以不同的架构模型为基础运行的。《Version Control By Example》一书的作者 Eric Sink 在他的书中对版本控制进行了分类，按其说法，Git 属于第三代版本控制系统，而大多数 Git 的前身，即流行于二十世纪九零年代和二十一世纪早期的系统，都属于第二代版本控制系统。 2 第三代版本控制系统是分布式的，第二代是集中式。你们以前大概都听过 Git 被描述为一款“分布式”版本控制系统。我一直都不明白分布式/集中式之间的区别，随后自己亲自安装了一款第二代的集中式版本控件系统，并做了相关实验，至少明白了一些。
我安装的版本系统是 CVS。CVS，即 “ 并发版本系统 Concurrent Versions System ” 的缩写，是最初的第二代版本控制系统。大约十年间，它是最为流行的版本控制系统，直到 2000 年被 Subversion 所取代。即便如此，Subversion 被认为是 “更好的 CVS”，这更进一步突出了 CVS 在二十世纪九零年代的主导地位。
CVS 最早是由一位名叫 Dick Grune 的荷兰科学家在 1986 年开发的，当时有一个编译器项目，他正在寻找一种能与其学生合作的方法。 3 CVS 最初仅仅只是一个包装了 RCS（ 修订控制系统 Revision Control System ) 的 Shell 脚本集合，Grune 想改进这个第一代的版本控制系统。 RCS 是按悲观锁模式工作的，这意味着两个程序员不可以同时处理同一个文件。需要编辑一个文件话，首先得向 RCS 系统请求一个排它锁，锁定此文件直到完成编辑，如果你想编辑的文件有人正在编辑，你就必须等待。CVS 在 RCS 基础上改进，并把悲观锁模型替换成乐观锁模型，迎来了第二代版本控制系统的时代。现在，程序员可以同时编辑同一个文件、合并编辑部分，随后解决合并冲突问题。（后来接管 CVS 项目的工程师 Brian Berliner 于 1990 年撰写了一篇非常易读的关于 CVS 创新的 论文。）
从这个意义上来讲，CVS 与 Git 并无差异，因为 Git 也是运行于乐观锁模式的，但也仅仅只有此点相似。实际上，Linus Torvalds 开发 Git 时，他的一个指导原则是 WWCVSND，即 “ CVS 不能做的 What Would CVS Not Do ”。每当他做决策时，他都会力争选择那些在 CVS 设计里没有使用的功能选项。 4 所以即使 CVS 要早于 Git 十多年，但它对 Git 的影响是反面的。
我非常喜欢折腾 CVS。我认为要弄明白为什么 Git 的分布式特性是对以前的版本控制系统的极大改善的话，除了折腾 CVS 外，没有更好的办法。因此，我邀请你跟我一起来一段激动人心的旅程，并在接下来的十分钟内了解下这个近十年来无人使用的软件。（可以看看文末“修正”部分）
CVS 入门
CVS 的安装教程可以在其 项目主页 上找到。MacOS 系统的话，可以使用 Homebrew 安装。
由于 CVS 是集中式的，所以它有客户端和服务端之区分，这种模式 Git 是没有的。两端分别有不同的可执行文件，其区别不太明显。但要开始使用 CVS 的话，即使只在你的本地机器上使用，也必须设置 CVS 的服务后端。
CVS 的后端，即所有代码的中央存储区，被叫做 存储库 repository 。在 Git 中每一个项目都有一个存储库，而 CVS 中一个存储库就包含所有的项目。尽管有办法保证一次只能访问一个项目，但一个中央存储库包含所有东西是改变不了的。
要在本地创建存储库的话，请运行 init 命令。你可以像如下所示在家目录创建，也可以在你本地的任何地方创建。
$ cvs -d ~/sandbox init
CVS 允许你将选项传递给 cvs 命令本身或 init 子命令。出现在 cvs 命令之后的选项默认是全局的，而出现在子命令之后的是子命令特有选项。上面所示例子中，-d 标志是全局选项。在这儿是告诉 CVS 我们想要创建存储库路径在哪里，但一般 -d 标志指的是我们想要使用的且已经存在的存储库位置。一直使用 -d 标志很单调乏味，所以可以设置 CVSROOT 环境变量来代替。
因为我们只是在本地操作，所以仅仅使用 -d 参考来传递路径就可以，但也可以包含个主机名。
此命令在你的家目录创建了一个名叫 sandbox 的目录。 如果你列出 sandbox 内容，会发现下面包含有名为 CVSROOT 的目录。请不要把此目录与我们的环境变量混淆，它保存存储库的管理文件。
恭喜！ 你刚刚创建了第一个 CVS 存储库。
检入代码
假设你决定留存下自己喜欢的颜色清单。因为你是一个有艺术倾向但很健忘的人，所以你键入颜色列表清单，并保存到一个叫 favorites.txt 的文件中：
blue
orange
green
definitely not yellow
我们也假设你把文件保存到一个叫 colors 的目录中。现在你想要把喜欢的颜色列表清单置于版本控制之下，因为从现在起的五十年间你会回顾下，随着时间的推移自己的品味怎么变化，这件事很有意思。
为此，你必须将你的目录导入为新的 CVS 项目。可以使用 import 命令：
$ cvs -d ~/sandbox import -m "" colors colors initial
N colors/favorites.txt
No conflicts created by this import
这里我们再次使用 -d 标志来指定存储库的位置，其余的参数是传输给 import 子命令的。必须要提供一条消息，但这儿没必要，所以留空。下一个参数 colors，指定了存储库中新目录的名字，这儿给的名字跟检入的目录名称一致。最后的两个参数分别指定了 “vendor” 标签和 “release” 标签。我们稍后就会谈论标签。
我们刚将 colors 项目拉入 CVS 存储库。将代码引入 CVS 有很多种不同的方法，但这是 《Pragmatic Version Control Using CVS》 一书所推荐方法，这是一本关于 CVS 的程序员实用指导书籍。使用这种方法有点尴尬的就是你得重新 检出 check out 工作项目，即使已经存在有 colors 此项目了。不要使用该目录，首先删除它，然后从 CVS 中检出刚才的版本，如下示：
$ cvs -d ~/sandbox co colors
cvs checkout: Updating colors
U colors/favorites.txt
这个过程会创建一个新的目录，也叫做 colors。此目录里会发现你的源文件 favorites.txt，还有一个叫 CVS 的目录。这个 CVS 目录基本上与每个 Git 存储库的 .git 目录等价。
做出改动
准备旅行。
和 Git 一样，CVS 也有 status 命令：
$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt Status: Up-to-date
Working revision: 1.1.1.1 2018-07-06 19:27:54 -0400
Repository revision: 1.1.1.1 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
Commit Identifier: fD7GYxt035GNg8JA
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
到这儿事情开始陌生起来了。CVS 没有提交对象这一概念。如上示，有一个叫 “ 提交标识符 Commit Identifier ” 的东西，但这可能是一个较新版本的标识，在 2003 年出版的《Pragmatic Version Control Using CVS》一书中并没有提到 “提交标识符” 这个概念。 （CVS 的最新版本于 2008 年发布的。 5 ）
在 Git 中，我们所谈论某文件版本其实是在谈论如 commit 45de392 相关的东西，而 CVS 中文件是独立版本化的。文件的第一个版本为 1.1 版本，下一个是 1.2 版本，依此类推。涉及分支时，会在后面添加扩展数字。因此你会看到如上所示的 1.1.1.1 的内容，这就是示例的版本号，即使我们没有创建分支，似乎默认的会给加上。
一个项目中会有很多的文件和很多次的提交，如果你运行 cvs log 命令（等同于 git log），会看到每个文件提交历史信息。同一个项目中，有可能一个文件处于 1.2 版本，一个文件处于 1.14 版本。
继续，我们对 1.1 版本的 favorites.txt 文件做些修改（LCTT 译注：原文此处示例有误）：
blue
orange
green
cyan
definitely not yellow
修改完成，就可以运行 cvs diff 来看看 CVS 发生了什么：
$ cvs diff
cvs diff: Diffing .
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 favorites.txt
3a4
> cyan
CVS 识别出我们我在文件中添加了一个包含颜色 “cyan” 的新行。（实际上，它说我们已经对 “RCS” 文件进行了更改；你可以看到，CVS 底层使用的还是 RCS。） 此差异指的是当前工作目录中的 favorites.txt 副本与存储库中 1.1.1.1 版本的文件之间的差异。
为了更新存储库中的版本，我们必须提交更改。Git 中，这个操作要好几个步骤。首先，暂存此修改，使其在索引中出现，然后提交此修改，最后，为了使此修改让其他人可见，我们必须把此提交推送到源存储库中。
而 CVS 中，只需要运行 cvs commit 命令就搞定一切。CVS 会汇集它所找到的变化，然后把它们放到存储库中：
$ cvs commit -m "Add cyan to favorites."
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v
