引言：
“如果你想要了解真正的历史，你需要回到在打孔卡上进行人工比对的年代。” —— Jim Rootham
在这个为鳕鱼编写传记都能够流行的年代，写一本记录程序员如何存储代码——他们最重要的劳动成果的书一点也不疯狂。
既然你和我都没有时间来阅读或编写这样的一本书，我们打算用这篇博客来进行探讨。
这是一个重要的问题。
（现在）版本控制产品非常普通而且很流行。
然而，它经历了几十年的不断创新。在这个领域里最聪明的人的努力下，代码管理变得非常简单而且有效。
每一步都是那么让人感到惊奇。
1. 源代码就是一个文本文件！（20世纪60年代）
现在看来，存储源代码和编写简单文档应该是一样的。但如果你简单读一下ASCII的历史就会知道，即使达成这样的共识也来之不易。
2. 人们可以手动跟踪代码版本！（20世纪60年代）
在没有软件的年代，所有事情都要从源代码开始。
“我工作的第一家公司有一个源码管理部门。当你把代码写好以后，将软盘交给源码管理部门一位漂亮女士。他们会及时更新函数库，用你的磁盘基于公司官方的代码构建产品交付给客户。” —— Miles Duke
3. 你可以为单个文件保留多个版本！（1972，1978）
采用奇特的交错编织文件格式，SCCS在版本控制领域称雄了10年之久。
记录单个文件的从一个版本到下一个之间的变化花费了几年的时间。“差异文件比较算法”是这个课题最近发表的一篇论文（1976）。
1982年，RCS反向使用diff文件（描述算法原文）打败了SCCS成为继任者，并让评论家大跌眼镜：
“一起出现的还有带有反向比较功能的RCS，我认为它非常棒。” —— 无名氏
4. 每个人都可以检出自己的拷贝！(1982)
在那个时候，人们工作时需要登录一台中央大型机并通过它一起工作。采用符号链接，RCS可以让每个人都工作在相同版本的代码上，而且每个人都有自己的工作拷贝。
“有一个叫做RCS的文件，实际上它十一个链接到RCS仓库的符号链接，你可以与其他小组成员一起使用。” —— 耶鲁大学RCS使用介绍
5. 喔！你可以一次给多个文件进行版本控制！（1986）
令人吃惊的是，直到CVS出现之前，版本控制系统都只支持单个文件。当然，你可以使用通配符让RCS提交多个文件或者标记特定分支。但这些并不是版本控制系统的一部分。
CVS默认会递归修改所有文件。突然之间，软件从单个目录或文件变成了文本文件的递归树。
虽然由于不具备“原子性”导致实现的产品不尽如人意（后来Subversion在2000年解决了这个问题），但是瑕不掩瑜。
6. 两个人可以同时编辑同一个文件，并将他们的工作合并在一起！（1986）
20世纪90年代末，我在Creature Labs工作。我们从Visual SourceSafe（商业软件，微软公司发布）转到CVS（开源软件，由一些嘻皮士发布）。
坦率的讲，大家都怀疑CVS能否做到它宣称的那样：让多个人同时编辑同一个文件，并将他们的修改没有错误地合并到一起而不造成其他问题。
在我们开发Creatures 3的时候，SourceSafe的互斥锁成为了一个大问题。我们当时要添加垃圾搜集功能，这个功能会影响到几乎所有的代码。这个时候，我们的首席程序员不得不在周末检出每一个文件然后进行修改。
1986年的这篇论文记录下了这个奇迹。当Dick Grune和他的团队在荷兰开发一个编译器的时候，他们遇到了同样的问题，CVS从此应运而生。
7. 可以在远程服务器上共享代码仓库！（1994）
大多数时候，人们只在一台机器上使用版本控制。在1986年，人们可以通过RCS的一些版本以及CVS提供的远程文件共享机制以拥有远程代码仓库。
“假如RCS的某个版本可以通过远程服务器访问，那么开发人员就可以在代码仓库之外的机器上进行开发了。” —— Dick Grune
然而，直到1994年TCP/IP协议的引入，这个想法才得以起步。
“直到Cygnus软件的Jim Blandy和Karl Fogel（这两位后来成为Subversion项目的主要开发者）为CVS发布了一些补丁，使得CVS客户端软件可以通过远程TCP/IP连接进行访问，CVS才真正变得无处不在。 ”—— Eric Raymond
8. 免费的开源版本控制主机服务！(1999）
这并不是源码管理技术的进步，但这的确是一个标志，Internet社区的发展与技术的进步同等重要：
“OSS以及成为历史，这已经成为一种趋势。John T. Hall 预见到，如果项目都是在线开发，那么之前开发的版本就在那里。开发平台服务是一种创新，但是没有人去做，我们就想‘为什么不呢？’”—— Brian Biles
就像末日狂欢那样（因为股票的原因），VA Linux把SourceForge带到了这个世界上。这对新项目是天大的好消息（例如我的TortoiseCVS）。
在当时，在Internet上获得一台服务器很困难而且非常昂贵，进行源码管理和bug追踪也是如此。这项新服务尽管缺乏商业模式，却让无数项目更早地面世。
译注：OSS：一个综合的业务运营和管理平台，同时也是真正融合了传统IP数据业务与移动增值业务的综合管理平台。
9. 没有主代码库，你可以向所有人发布！（2005）
在21世纪头10年，有一股将版本控制实现完全分布式的潮流。
也就是说，在你本地的机器上存放的是一份完整的代码历史，可以轻易地与任何其他拷贝进行分支和合并。顺带说一下，也正是这个特性使得分支和合并变得更加容易。
我并没有记录某个第一次发明这种工具，而是按照它产品化以及流行的时间进行统计。鉴于此，将它定在2005年似乎有些不公平。Mercurial和Git发布于2005年4月。
这篇“分布式版本控制风险”（2005年底）介绍了这个革命性的创新。
10. 当你检出一个fork，你可以让大家都看到！（2008）
GitHub的成功有很多原因（尽管我之前提到过一些，要讲清楚这个问题还是需要单独写一篇文章讨论）。
关键在于，你可能甚至可以将一些自己做的不大的改动提交到别人的公共代码上。在GitHub之前，一般我们会保存在自己的电脑上。
如今，只需要简单做一个fork，或者甚至可以直接在浏览器上编辑，这样任何人都可以马上发现你代码中的bug。
尾声
快速回顾一下这几十年的进展。是的，计算机的发展做出了贡献。但更主要的是，这些都是人们为更好地协作而贡献出的聪明才智。
这让我想到，下一个会是什么？在版本控制领域还会有什么令人惊叹的事情发生？
推而广之，同样的事情会在其它领域发生吗？
作为核心信息基础设施，这种巨大的改进能够最终改善政府、医疗、新闻或者数据领域创新的障碍吗？
我有这种感觉，我们就要找到答案了。
想了解更多吗？请阅读《版本控制时间轴》（发表于Plastic SCM的博客，不要忘记看一下评论）以及《理解版本控制系统》