关于版本控制系统

按照时间顺序记录某一系列的文件的变更，使其可以查看以前的特定版本的软件，我们称之为版本控制系统。

简单来讲：创建两个文件夹，在两个文件夹中分别保存一月份与二月份的销售数据，这样就创建了一个简单且稳定的版本控制系统。

常见的版本控制系统

在 MacOS 上，只要你安装了开发者工具，就会包含一个 rcs 命令。RCS 会在磁盘上以一种特殊的格式保存补丁集。当你需要某个版本的内容时，我们通过叠加补丁集，来恢复到某个历史的状态。

Subversion

和 RCS 类似，Subversion 在中央服务器上保存了每个版本的 patch set。当用户进行检出时，我们检出的实际上是检出版本对应的补丁集数据。显而易见：如果中央服务器发生异常，将导致检出与提交功能无法使用，继而造成版本控制系统的瘫痪。

为什么 Git 与众不同

其他版本控制系统的文件存储设计

Git 与上述版本控制系统最大的不同在于其对待数据的方式。概念上来区分，其它大部分系统以文件变更列表的方式存储信息。这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。

Version1 保存了3个文件 A、B、C。
Version2 File A 与 File C 发生了变化，版本控制系统将变化的补丁集保存下来。File B 未发生任何变化。

如下图所示：当需要恢复到某个历史版本时，需要从中央服务器上拉去补丁集，并叠加恢复到某一时间段的状态。

Git 版本控制系统的文件存储设计

Git 不按照以上方式对待或保存数据。反之，Git 更像是把数据看作是对小型文件系统的一组快照。每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个快照流。

Version1 保存了3个名称为 A、B、C 的文件。
Version2 文件 A、C 发生了变化，版本保存了变化后的文件。文件 B 没有发生任何变化，版本保留了一个指向 File B 的链接。

由于 Git 的快照同步机制，只需要同步一次服务器上的版本数据信息，即可在本地恢复到任何一个版本。另外，无论哪一台客户机的数据发生了丢失，都可以随时同步其他客户机的数据恢复作业，这就是分布式的含义。从本质上来说，Git 不再是一种一个单纯的版本控制系统，而更像是一个微型文件系统。

Git 的完整性校验

在计算机中，哈希算法经常用来做签名校验，以保证内容的完整性，Git 也一样。在 Git 中所有数据在存储前都计算校验和，然后以校验和来引用。Git 用来计算校验和的机制叫做 SHA-1 散列（hash，哈希）。基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样

24b9da6552252987aa493b52f8696cd6d3b00373

Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。

结语

简单总结一下本章的内容：

传统的版本控制系统，保存的是文件变化的补丁集。
分布式文件系统 Git 保存的是文件的快照流，不是变化的补丁集。
Git 使用 hash 算法来对文件进行引用。

参考书籍《精通 Git pro 第二版》

若文章有幸帮到了您，您可以捐助我。以鼓励我写出更棒的作品！

Git 分布式文件系统 - 为什么 Git 与众不同？