版本控制的演变与Git基础知识

关于版本控制

　　版本控制用来记录一个或若干文件内容变化，以便将来查阅特定版本修订情况。 有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态，比较文件的变化细节等等。 版本控制和系统备份很像，就算把系统搞坏了，你也可以恢复到原先的样子。

本地版本控制系统

　　很久前直至现在，我们有时候会复制文件，通过时间或特殊标记来进行文件的备份。这么做唯一的好处就是简单，但是特别容易犯错。这样做很方便，但是很容易忘记具体版本，或是写错文件覆盖意文件。为了解决这个问题，人们开发了许多种本地版本控制系统，大多都是采用某种数据库来记录文件的历次更新差异。

　　其中最流行的一种叫做RCS。它的工作原理是在硬盘上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各个版本的文件内容。

集中化的版本控制系统

　　对于开发人员又产生了新的问题：在不同系统上的开发者如何协同工作？ 于是，集中化的版本控制系统（Centralized Version Control Systems，简称 CVCS）应运而生，诸如 CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。现在，每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限，并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。

　　但是这方法的缺点是中央服务器的单点故障，在这段时间内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，将丢失所有数据——包括项目的整个变更历史，只剩下在各自机器上检出的快照。

　　

分布式版本控制系统

　　因为上面的种种原因才有了分布式版本控制系统（Distributed Version Control System，简称 DVCS），像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份。

数据存储方式

　　大部分系统以文件变更列表的方式存储信息。 这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。



　　Git 和其它版本控制系统主要差别在于对待数据的方法。Git 在每次提交更新，或在 Git 中保存项目状态时，会对全部文件制作一个快照并保存这个快照的索引。 如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。



　　存储项目随时间改变的快照，虚线包裹表示链接指向之前存储的文件。Git 更像是一个小型的文件系统，提供了许多以此为基础构建的超强工具，而不只是一个简单的 VCS。

Git 保证完整性

　　Git 中所有数据在存储前都计算校验和，然后以校验和来引用。 所以不可能在 Git 不知情时更改任何文件内容或目录内容，比如在传送过程中丢失信息或损坏文件，Git 就能发现。

　　Git 用以计算校验和的机制叫做 SHA-1 散列（hash，哈希）。 这是一个由 40 个十六进制字符（0-9 和 a-f）组成字符串，基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样：24b9da6552252987aa493b52f8696cd6d3b00373。Git 中使用这种哈希值的情况很多，Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。

　　我们难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。 未提交更新时有可能丢失或弄乱修改的内容；但是一旦你提交快照到 Git 中，就难以再丢失数据。

Git 与 SVN 区别

GIT是分布式的，你的很多操作可以在本地完成：最核心的区别。

GIT把内容按元数据方式存储，而SVN是按文件。

GIT分支和SVN的分支不同：分支在SVN中一点不特别，相当于版本库中的另外的一个目录。

GIT没有全局的版本号，SVN有。

GIT的内容完整性要优于SVN：GIT的内容存储使用的是SHA-1哈希算法。