GIT 之概述与架构

1,115 阅读9分钟

GIT是如今最流行的版本控制系统。曾经系统总结过一次关于GIT的使用,抽时间整理成文。

基础概念

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

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

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

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

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

  • 记录文件所有历史变化。这是版本控制系统的基本能力;
  • 随时恢复到任意时间点。历史记录功能使我们不怕改错代码了;
  • 支持多功能并行开发。通常版本控制系统都支持分支,保证了并行开发的可行;
  • 多人协作并行开发。对于多人协作项目,支持多人协作开发的版本管理将事半功倍;

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

常见类别

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

  • 本地版本控制系统、
  • 集中式版本控制系统、
  • 分布式版本控制系统;

本地版本控制系统

代表有RCS(Revision Control System),Linux下面的可用来作为配置文件管理的版本控制工具,本人尝试了一下,工作使用不多;

local_version_control.png

关于其优缺点,简述如下:

优点

  • 简单,很多系统中都有内置;
  • 适合管理文本,如系统配置;

缺点

  • 管理少量文件,不支持项目的管理;
  • 支持的文件类型单一;
  • 不支持远程,网络传输;

集中式版本控制系统

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

centralized_version_control.png

优点

  • 适合多人团队协作开发;
  • 代码集中化管理;

缺点

  • 单点故障;
  • 必须联网,无法单机工作;

优点就不多说了,大家可能对缺点更是记忆深刻。 单点故障,集中式管理的缺点,代码集中在一台机器上,这个问题其实可以通过备份集群解决;

必须联网工作,这个缺点我是深入痛觉,一旦公司网络出现问题,几个小时甚至一天无法工作的经历都有。由于这些缺点,便有了分布版本控制系统。

分布式版本控制系统

分布式版本控制系统的代表就是今天要介绍的 GIT 了。想知道 GIT 有多流行吗?看看 Github 就知道了,现在很多公司都已经把自己的代码库迁移到了 GIT。本人由于各种原因,近两年已经到了第三家公司,其中每家都听过一次 GIT 的分享。可见 Git 在如今的流行程度,也说明了分布式版本控制系统是如今的趋势。

distributed_version_control.png

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

  • 适合多人团队协作开发;
  • 代码集中化管理;
  • 可以离线工作;
  • 每个计算机都是一个完整仓库;

1、2两点 svn 也可以做到,说一下3、4点。

可以离线工作,分布式版本管理系统每个计算机都有一个完整的仓库,可本地提交,可以做到离线工作。没有了 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与SVN的部分差异。

GIT架构

GIT的架构,可以分为几个部分:

  • 本地工作区(working directory)
  • 暂存区(stage area, 又称为索引区, index)、
  • 本地仓库(local repository)、
  • 远程仓库副本
  • 远程仓库(remote repository)。

如下图:

git_structure.png

上图展示了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这个目录的下文件结构,如下图:

dot_git_repository.png

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

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的架构也进行整体简单介绍。内容比较理论,期望在理清自己思路的同时,不会误导他人。

好了,就说这么多!文中如有错误,请帮忙指正!谢谢!

参考附录