接下来了解下什么是版本控制?

1、本地版本控制系统

许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的好处就是简单。不过坏处也不少：有时候会混淆所在的工作目录，如果弄错文件丢了数据就没法撤销恢复。为了解决这个问题开发了许多种本地版本控制系统，大多都是采用某种简单的数据库来记录文件的历次更新差异

其中最流行是rcs，许多计算机系统上有应用。在流行的MacOSX系统上安装了开发者工具包后可以使用rcs命令。工作原理基本上就是保存并管理文件补丁。文件补丁是一种特定格式的文本文件，记录着对应文件修订前后的内容变化。根据每次修订后的补丁，rcs可以通过不断打补丁，计算出各个版本的文件内容。

2、集中化的版本控制系统

如何让在不同系统上的开发者协同工作?于是，集中化的版本控制系统CVCS应运而生。这类系统，诸如CVS，Subversion以及Perforce等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。多年以来，成为版本控制系统的标准做法。

集中化的版本控制系统许多优势，相较于老式的本地VCS来说。每个人都可以在一定程度上看到项目中的其他人正在做些什么。而管理员也可以轻松掌控每个开发者的权限，并且管理一个CVCS要远比在各个客户端上维护本地数据库来得轻松容易。

缺点是中央服务器的单点故障。如果宕机一小时，谁都无法提交更新，也就无法协同工作。要是中央服务器的磁盘发生故障，碰巧没做备份，或者备份不够及时，就还是会有丢失数据的风险。最坏的情况是彻底丢失整个项目的所有历史更改记录，而被客户端提取出来的某些快照数据除外，但这样的话依然是个问题，你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。

3、分布式版本控制系统：

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