1. 关于版本控制

版本控制是一种记录一个或若干 文件内容变化，以便将来 查阅特定版本修订情况 的系统

有了它就可以将某个文件回溯到之前的状态
甚至将整个项目都回退到过去某个时间点的状态

可以比较文件的变化细节，查出最后是谁修改了哪个地方
从而找出导致怪异问题出现的原因，又是谁在何时报告了某个功能缺陷等等

使用版本控制系统（VCS）通常还意味着
就算乱来一气把整个项目中的文件改的改，删的删
也照样可以轻松恢复到原先的样子
但额外增加的工作量却微乎其微

2. 本地版本控制系统

许多人习惯用 复制整个项目目录 的方式来保存不同的版本
或许还会改名 加上备份时间以示区别
这么做唯一的好处就是简单，但是特别容易犯错
有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件

为了解决这个问题，很久以前就开发了许多种本地版本控制系统
大多都是采用某种简单的数据库来记录文件的历次更新差异

在这里插入图片描述
其中最流行的一种叫做 RCS
它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）
通过应用所有的补丁，可以重新计算出各个版本的文件内容

3. 集中式版本控制系统

接下来又遇到一个问题，如何让在不同系统上的开发者协同工作？

于是，集中式版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生

这类系统，诸如 CVS、Subversion 以及 Perforce 等
都有一个单一的集中管理的服务器，保存所有文件的修订版本
而协同工作的人们都通过客户端连到这台服务器
取出最新的文件或者提交更新

多年以来，这已成为版本控制系统的标准做法

在这里插入图片描述
这种做法带来了许多好处，特别是相较于老式的本地 VCS 来说
现在，每个人都可以在一定程度上 看到项目中的其他人正在做些什么
而管理员也可以 轻松掌控每个开发者的权限

事分两面，有好有坏
这么做最显而易见的缺点是中央服务器的单点故障
如果宕机一小时，那么在这一小时内，谁都无法提交更新，也就无法协同工作
如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问将丢失所有数据

本地版本控制系统也存在类似问题
只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险

4. 分布式版本控制系统

于是分布式版本控制系统（Distributed Version Control System，简称 DVCS）面世了

在这类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等
客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来
这么一来，任何一处协同工作用的服务器发生故障
事后都可以用任何一个镜像出来的本地仓库恢复
因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份

在这里插入图片描述
更进一步，许多这类系统都可以指定和若干不同的远端代码仓库进行交互
籍此，就可以在同一个项目中，分别和不同工作小组的人相互协作
可以根据需要 设定不同的协作流程，比如层次模型式的工作流
而这在以前的集中式系统中是无法实现的