基础概念

GIT是一种版本控制软件，那就首先了解一下什么是 “版本控制”？

比较官方的解释是，版本控制系统是一种记录一个或若干个内容变化，以便将来查询特定版本修订情况的系统。

简言之，你的修改只要提到到版本控制系统，基本都可以找回，版本控制系统就像一台时光机器，可以让你回到任何一个时间点。

了解了版本控制系统的功能，我们知道就算你把代码改的一塌糊涂，照样可以恢复到我们过去的任何一个时间点，工作量却微乎其微。是不是很amazing。

总结一下版本控制系统有哪些优点：

记录文件所有历史变化。这是版本控制系统的基本能力；

随时恢复到任意时间点。历史记录功能使我们不怕改错代码了；

支持多功能并行开发。通常版本控制系统都支持分支，保证了并行开发的可行；

多人协作并行开发。对于多人协作项目，支持多人协作开发的版本管理将事半功倍；

除了上面介绍的几个比较常见的优点，版本控制系统的好处还有很多，就不一一列举了，可通过实践自己逐渐体悟总结。下面基于GIT做更多介绍。

常见类别

版本控制系统常见类别有三种：

本地版本控制系统、

集中式版本控制系统、

分布式版本控制系统；

本地版本控制系统，代表有RCS(Revision Control System)，Linux下面的可用来作为配置文件管理的版本控制工具，工作使用不多；

关于其优缺点，简述如下：

优点：

简单，很多系统中都有内置；

适合管理文本，如系统配置；

缺点：

管理少量文件，不支持项目的管理；

支持的文件类型单一；

不支持远程，网络传输；

集中式版本控制系统，代表如CVS，SVN(Subversion)，SVN是曾经最流行的版本管理系统，很多人都有用过，因而对于集中式版本控制系统很多人都很了解它。

优点：

适合多人团队协作开发；

代码集中化管理；

缺点：

单点故障；

必须联网，无法单机工作；

优点就不多说了，大家可能对缺点更是记忆深刻。

单点故障，集中式管理的缺点，代码集中一台机器上，这个问题其实可通过备份集群解决；

必须联网工作，这个缺点深恶痛觉，一旦公司网络出现问题，几个小时甚至一天无法工作；

由于这些缺点，便有了分布版本控制系统。

分布式版本控制系统，代表就是今天要说的GIT了。想知道GIT有多流行吗？看看GITHUB就知道了，现在很多公司都已经把自己的代码库迁移到了GIT。可见GIT在如今的流行程度，也说明分布式版本控制系统是如今的趋势。如下基本架构图：

关于分布式版本控制系统，这里只说优点：

适合多人团队协作开发；

代码集中化管理；

可以离线工作；

每个计算机都是一个完整仓库；

前面两点SVN也可以做到，说一下后两点。

可以离线工作，分布式版本管理系统每个计算机都有一个完整的仓库，可本地提交，可以做到离线工作。没有了SVN令人抓狂的断网无法工作问题;

每个计算机都是一个完整的仓库，也就没有了SVN的单点故障。

GIT与SVN的比较

GIT的作者Linus一直比较痛恨集中方式版本控制系统。虽然有很多已知免费的集中式版本控制系统，但是在2002之前提交Linux源码的方式都是通过diff提交给Linus的，然后进行手工合并。下面让我们来以GIT与SVN作为代表，来看看为什么Linus痛恨集中式版本管理系统，而喜欢分布式版本管理系统。下面具体比较一下它们的区别：

GIT是分布式的，SVN为集中式的。常识，两者最重要的区别，也是后面所有区别的基石；

GIT随处都是版本库，SVN只有一个中央版本库。因为GIT是分布式的所以能做到到处都是版本库，而SVN是集中式的，所以只有一个中央仓库。因而GIT能够做到无需网络提交，到处到时版本库，压根不用担心提交速度问题，不用时刻依赖与网络工作，不用担心单点故障。当工作完成之后直接推送远程即可实现工作协作；

GIT没有全局版本号，SVN有全局版本号。GIT版本库到处都是，之间没有实时共享数据，所以无法确保版本号的唯一性，无法使用全局版本号，分布在各个机器上的版本库版本号使用40位的HASH值取代。重复的情况是存在的，从数学的角度考虑，可能性是2的63次方分之一，基本可忽略。而对于SVN，唯一版本，所以能够做到使用全局的版本号，版本号采用自增的方式；

GIT把内容按元数据存储，SVN按文件存储。GIT存储的不是实际的文件，而是指向性数据。SVN保存的是文件数据。当GIT切换版本的时候，实际上切换的是元数据，而且本地操作，快捷有效；

GIT记录文件快照，SVN记录文件差异。GIT的元数据，即指向性数据指向的是实际的文件快照，这也是GIT能够快速切换版本的一个原因。SVN保存的文件数据是各个版本之间的文件差异，所以切换版本的时候需要逐级的差异计算，速度比较慢，而且还需网络传输。当工程较大时，速度与GIT相比差异会相当的大。

GIT的内容完整性高，SVN完整性低。因为GIT的数据记录都有HASH值校验，所以内容完整性较高。而SVN则没有此功能，内容完整性低。；

GIT架构

GIT的架构，可以分为几个部分：

本地工作区(working directory)

暂存区(stage area, 又称为索引区, index)、

本地仓库(local repository)、

远程仓库副本

远程仓库(remote repository)。

如下图：

上图展示了git的整体架构，以及和各部分相关的主要命令。先说明下其中涉及的各部分。

工作区(working directory)，简言之就是你工作的区域。对于git而言，就是的本地工作目录。工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。

暂存区(stage area, 又称为索引区index)，是git中一个非常重要的概念。是我们把修改提交版本库前的一个过渡阶段。查看GIT自带帮助手册的时候，通常以index来表示暂存区。在工作目录下有一个.git的目录，里面有个index文件，存储着关于暂存区的内容。git add命令将工作区内容添加到暂存区。

本地仓库(local repository)，版本控制系统的仓库，存在于本地。当执行git commit命令后，会将暂存区内容提交到仓库之中。在工作区下面有.git的目录，这个目录下的内容不属于工作区，里面便是仓库的数据信息，暂存区相关内容也在其中。

远程版本库(remote repository)，与本地仓库概念基本一致，不同之处在于一个存在远程，可用于远程协作，一个却是存在于本地。通过push/pull可实现本地与远程的交互；

远程仓库副本，可以理解为存在于本地的远程仓库缓存。如需更新，可通过git fetch/pull命令获取远程仓库内容。使用fech获取时，并未合并到本地仓库，此时可使用git merge实现远程仓库副本与本地仓库的合并。

GIT文件一览

看看.git这个目录的下文件结构，如下图：

简要说明一下各个文件中所存放的内容信息：

HEAD，当前所在位置，其实就是工作区的在版本库中的那个提交点，最终会指向一个40位的HASH值；

config，当前版本库的专有配置文件，如使用命令git config user.name poloxue便会记录在此文件；

description，被gitweb (Github的原型)用来显示对repo的描述。

hooks，git有可自动运行在 git 任有意义阶段的脚本hooks, 如commit/release/pull/push等状态之前或者之后。个人思考的一个用处，如pre-push可以用来强制进行代码检查。

index，存放暂存区(stage area)的相关信息；

info/exclue，可以做到和.gitignore相同的事情，用于排除不要包含进版本库的文件。区别就是，此文件不会被共享。

refs/heads，目录下有关于本地仓库的所有分支；

refs/remote，目录下有关于远程仓库的所有分支；

object，目录下存放的就是实际的数据文件，关于其中的存放方式暂时还不了解，有兴趣可以研究一下；

本节从版本控制引出分布式版本控制，比较分布式版本控制系统与其他版本控制系统的区别，从而引入GIT。与SVN的比较明显可看出GIT的优秀之处。对GIT的架构也进行整体简单介绍。内容比较理论，期望在理清自己思路的同时，不会误导他人。