分布式版本控制VS集中式版本控制

集中式版本控制

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

 如上图所示，A、B、C为三位开发者，这是A将代码拉到本地进行开发，这个时候A开发完成后将代码提交到服务器这是就形成了一个历史版本。此时B再去拉取A提交的代码到本地去做下一个版本的开发，以此类推，集中式版本控制就是这样进行的。

这种做法带来了很多好处，每个人都能在一定程度上看到项目中其他人正在做些什么，管理员也可以轻松掌握每个开发者的权限，并且管理一个集中化的版本控制系统，要远比在各个客户端上维护本地数据库来得轻松容易。

但是集中化版本控制的缺点是当中央服务器出现单点故障时，故障期间，谁都无法提交更新，也就无法协同工作。

分布式版本控制

最流行的分布式控制工具当属git，像git这种分布式版本控制工具，客户端提取的不是最新的版本的文件快照，而是把代码仓库完整的镜像下来（本地库），这样任意一处协同工作用的文件发生故障，事后都可以用其他客户端的本地仓库进行恢复，因为每个客户端每一次文件提取操作，实际上都是一次对整个仓库文件的备份。

分布式版本控制的出现解决了集中式版本控制系统的缺陷：

1、服务器断网的情况下也可以进行开发（因为版本控制是在本地进行的）

2、每个客户端保存的也就是完整的项目（包含历史记录，更加安全）

如图，A、B、C三个客户端都会完整的保存整个项目的代码，对代码进行修改之后的版本记录会保存在本地，这个时候会有一个远程的代码库，假如A对代码进行了修改此时A把修改的代码推送到了远程库，这个时候B就先将远程库的代码拉取到本地之后再进行开发。这样的好处就在于所有的历史版本都会在本地进行记录，代码远程库（像github、gitee等）就算出现了故障也不会影响太大，因为版本控制是在本地进行的，只是暂时的不能将最新的代码提交到远程库。