第二章 集中式和分布式版本控制

前面已经说过，我们为什么需要版本控制。

而在版本管理软件的具体实现上，人类经过了两个阶段。

第一阶段   集中式版本控制

理念非常简单，通过一个单一的集中式服务器，保存所有的文件修订版本。

当用户修改了文件后，发送到服务器上，服务器和原文件进行对比，记录下变化的内容。

变化的内容包括修改时间，修改人，修改的具体内容，所以更形象的说服务器保存了各种文件“补丁”。

缺点在于如果服务器发生死机，则所有用户都无法提交更新，也就无法协同工作。

如果服务器磁盘发生故障，还有可能丢失部分或者全部项目数据。

同时协同工作时，需要联网才能使用。

我们可以把这种模式想象成学校图书馆。

图书馆统一管理所有图书，而学生则从图书馆借走（归还）图书。

图书馆具有至高无上的地位，学生们借走（归还）图书都需要围绕它进行。

 

 

第二阶段   分布式版本控制

理念也非常简单，任何一个用户都是一个“服务器”。

因此分布式版本控制，并不关心文件变化的内容，它只关心文件是否有改变，如果有，那么就备份。

虽然在结构上依然要使用服务器，但此时的服务器没有至高无上的地位，它起到的更多是方便“交换”作用。

因为每一个用户都相当于服务器，不仅所有的文件都被完整的“拷贝”，版本控制的工具也可以在用户机器上任意使用，所以分布式版本控制无需联网。

我们可以把这种模式想象成动画片的“分身术”，每一个分身都和本体相同。

要学习的git就属于分布式版本控制，它有以下特点：

①速度快

②设计简单

③对非线性开发模式的强力支持，允许上千个并行开发的分支

④有能力高效管理类似linux内核一样（千万代码级）的超大规模项目

git是由linux系统的缔造者linux Torvalds开发的，网络上还流传着一则故事（不知真假）：

Linus虽然创建了Linux系统，但Linux系统的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux系统编写代码，那Linux的代码是如何管理的呢？

事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码。

不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了。

于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。

BitKeeper是商用软件，肯定是闭源的，而linux系统完全属于免费开源，两者精神有点格格不入。

社区里的一位仁兄叫做Andrew，他试图破解BitKeeper的协议，被BitMover公司发现，于是BitMover公司怒了，要收回Linux社区的免费使用权。

Linus Torvalds觉得求人不如求己，花了两周时间自己用C语言写了一个分布式版本控制系统，这就是Git！

一个月之内，Linux系统的源码已经由Git管理了！