版本控制系统（Version Control System，VCS）让我们能够将选定的文件回溯到之前的状态，甚至将整个项目回退到过去某个时间点。我们可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因。



## 集中式与分布式对比


| 特性   | 集中式（如 SVN、CVS）       | 分布式（如 Git、Mercurial）             |
| ---- | -------------------- | -------------------------------- |
| 存储位置 | 单一中央服务器，保存所有修订版本     | 每个人电脑上都有完整仓库镜像（含历史）              |
| 离线工作 | 需要联网才能操作             | 完全离线工作，推送时才需要网络                  |
| 数据安全 | 中央服务器损坏且无备份，则丢失所有历史  | 任何一份本地仓库都可恢复全部历史                 |
| 协作方式 | 从中央服务器取最新版 → 工作 → 推送 | 可互相推送，但常用“中央服务器”作为交换节点（如 GitHub） |
| 典型系统 | Subversion (SVN)、CVS | Git、Mercurial                    |

为了减小存储大小，分布式系统会使用压缩算法（如 Git 的 `git gc` 打包对象）。

> **扩展阅读**：[[Git 核心概念与基础操作]]、[[Git 内部原理]]

## 集中式（Centralized VCS）

集中式版本库集中存放于一个单一的中央服务器，保存所有文件的修订版本。协同工作时，人们需要先从中央服务器取得最新版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。
![](https://git-scm.com/book/en/v2/images/centralized.png)
## 分布式（Distributed VCS）

分布式版本控制系统根本没有“中央服务器”，每次是把代码仓库完整地镜像下来，包括完整的历史记录。这使得每个人的电脑上都是一个完整的版本库，不仅仅是最新版本的文件快照。

这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。同时，也不需要联网就可以进行工作。


![](https://git-scm.com/book/en/v2/images/distributed.png)

> 在实际使用分布式版本控制系统时，很少直接在两个人之间的电脑上推送修改（因为可能不在同一局域网）。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑或服务器（如 GitHub），但这个服务器的作用仅仅是方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。这也是我们在 GitHub 建立 repo 的原因。

### Git 的额外优势

Git 默认保存文件**快照**而非差异，并且会存储全部历史版本和最新版本。关于 Git 如何高效存储，请参见 [[Git 内部原理]]。