版本管理就是管理更新的历史记录。它为我们提供了一些在软件开发过程中必不可少的功能，例如记录一款软件添加或更改源代码的过程，回滚到特定阶段，恢复误删除的文件等。
在Git出现以前，人们普遍采用Subversion等集中型版本管理系统，而现在Git已经成为了主流。由于GitHub的普及，想必世界上使用Git的人会越来越多。因此要学习版本管理的各位，建议您选择Git。
●集中型与分散型
刚才我们提到版本管理系统分为Subversion这类集中型的与Git这类分散型的，下面就为各位简单说明一下二者的不同点。
集中型
以Subversion为代表的集中型，会如图2.1所示将仓库集中存放在服务器之中，所以只存在一个仓库。这就是为什么这种版本管理系统会被称作集中型。
集中型将所有数据集中存放在服务器当中，有便于管理的优点
。但是一旦开发者所处的环境不能连接服务器，就无法获取最新的源代码，开发也就几乎无法进行。服务器宕机时也是同样的道理，而且万一服务器故障导致数据消失，恐怕开发者就再也见不到最新的源代码了。
分散型
图2.2是以Git为代表的分散型的示意图。如图中所示，GitHub将仓库Fork给了每一个用户。Fork就是将GitHub的某个特定仓库复制到自己的账户下。Fork出的仓库与原仓库是两个不同的仓库，开发者可以随意编辑。
如图所示，分散型拥有多个仓库，相对而言稍显复杂。不过，
由于本地的开发环境中就有仓库，所以开发者不必连接远程仓库就可以进行开发
。
图中只显示了一般的使用流程。实际上，所有仓库之间都可以进行push和pull。即便不通过GitHub，开发者A也可以直接向开发者B的仓库进行push或pull。因此在使用前如果不事先制定规范，初学者往往会搞不清最新的源代码保存在哪里，导致开发失去控制。
●集中型与分散型哪个更好
要说集中型与分散型哪个更好，其实双方都各有优缺点，需要看具体情况而定。不过，随着Git与GitHub的普及，今后使用分散型的开发者将会占绝大多数。只要规则制定得当，分散型同样能像集中型那样进行管理。
有些人在学习版本管理的相关知识时，认为该从相对简单的集中型入手，再循序渐进学习分散型。但笔者认为，今后用到集中型的机会很少，所以不必特地绕这个弯路。
同样，建议想给团队导入版本管理系统的读者选择GitHub与Git。如果软件开发进行到一半再从集中型转为分散型，不但需要支付高额的费用，还要让开发者花费大量的精力与金钱去重新学习。考虑到今后的各种机遇与挑战，从一开始就选择分散型，必定是各位成功路上的关键一步。
只要脑中掌握了多个仓库并存的概念，学习分散型并不是什么难事。而且对于刚刚接触这方面知识的人来说，由于没有先入为主的干扰，应该很容易接受这一概念。