版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。除了项目,你可以对任何类型的文件进行版本控制。
采用版本控制系统(VCS)是个明智的选择。有了它就可以将某个文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态,可以比较文件的变化细节,查出最后是谁修改了哪个地方,从而找出导致怪异问题出现的原因,又是谁在何时报告了某个功能缺陷等等。使用版本控制系统就算你对项目删除,修改错误,这也没有关系,你也照样可以很容易地就恢复到原先的样子,但额外增加的工作量却微乎其微。
许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单,但是特别容易犯的错。有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。而且不利于团队协作。 为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异。图片来源Git官网。
其中最流行的一种叫做RCS,现今许多计算机系统上都还看得到它的踪影。甚至在流行的Mac OS X系统上安装了开发者工具包之后,也可以使用 <代码> rcs 命令。它的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化),通过应用所有的补丁,可以重新计算出各个版本的文件内容。
接下来人们又遇到一个问题,如何让在不同系统上的开发者协同工作?于是,集中化的版本控制系统(集中式版本控制系统中,简称 <代码> cvc> CVS> SVN> 等。 集中化的版本控制系统是单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。多年以来,这已成为版本控制系统的标准做法。如图(来源Git官网):
相对本地版本管理,集中化的版本控制每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个cvc要远比在各个客户端上维护本地数据库来得轻松容易。
它也有如下诟病:
-
<李>
<>节
<强>单点故障强如果宕机,谁都无法提交更新,也就无法协同工作。如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问将丢失所有数据,包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。
<李> <>节<强>需要联网为什么需要联网吗? <代码>集中化的版本控制系统>
于是分布式版本控制系统(分布式版本控制系统,简称 <代码> DVCS> 就是典型的分布式版本控制。还有 <代码> Mercurial代码> 集市> Darcs 等。
客户端并不只提取最新版本的文件快照,而是把代码仓库完整地镜像下来。这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。图片来源Git官网。
分布式版本控制系统的优势不单是不必联网这么简单,后面我们还会看到Git极其强大的分支管理等功能。
2002年, Linux <代码> 内核开源项目整个项目组启用一个专有的分布式版本控制系统BitKeeper来管理和维护代码。到2005年了,开发BitKeeper的商业公司同Linux内核开源社区的合作关系结束,他们收回了Linux内核社区免费使用BitKeeper的权力。这就迫使Linux开源社区(特别是Linux的缔造者Linus Torvalds)基于使用BitKeeper时的经验教训,开发出自己的版本系统。
