关于GIT你需要知道的123344N

Git对于软件开发人员并不陌生，可以说，在很多软件开发人员的日常工作中，Git的使用频率是进入TOP榜的。但是，说起对Git原理的了解，估计就没有多少人了。很多人是抱着会用就可以了的心态。其实，了解背后的原理，可以激发你做更具创新性的工作。下面，我们简单整理Git的内部实现原理，并通过一组简单的数字串起来，以此提升大家对Git的认知。

关于Git的123344N
Git的本质是用于分布式版本管理的框架协议。类似于类Unix的设计哲学，Git也有自己的一套设计理念。具体包括：

1 一条分支网络

分支网络管理了版本的分支关系、提交记录、历史视图。不同于svn中，分支是一个完整的拷贝，git的分支本质上是一个记录集合（通过指针指向），并不存在所谓传统意义上的分支，而是统一在整个变化网络中，真正实现了节点级别的抽象。（下图来自git pro，如无特殊说明，后续图片均采集自Git - 分支简介GitGit - 分支简介）

2 Git维护两种主要关系：

文件之间的层级关系和文件本身的副本关系。第一层关系基于操作系统；第二层关系维护了版本关系。

通过第一层关系，可以梳理出整个工程的文件目录树结构。通过第二层关系，可以对每个版本的每个文件快速做出处理。不同于其他版本控制系统，Git并不记录文件的差异，而是创建文件的全新副本，并通过指针维护它们之间的关系。这种底层理念决定上上层操作的差异。几乎所有的修改都在本地，只需要在本地就可以完成所有操作，性能自然可以有质的提升。

3 Git提供三级配置

全局级别配置，一般处于/etc目录下。用户级别配置，一般处于用户目录下。项目级别配置，处于仓库目录下。下一级配置覆盖上一级，满足更加定制化的需求。

这一点跟面向对象中的子类重写父类有一定的相似之处。跟C语言中变量作用域也有类似之处。

4 Git提供三个区

工作区，当前工作目录。暂存区，将工作区的修改纳入版本管理。提交区，用于记录提交及同步仓库。

5 Git文件有四种状态：

未被跟踪状态，已跟踪但未修改状态，已跟踪且修改但未提交状态，已跟踪且修改且提交状态。纳入版本管理的文件在后三种状态间循环。

6 Git内部实现四种对象：

blob对象，指代实体文件；tree对象，管理blob对象的差异；commit对象，记录提交信息；tag对象，记录tag信息。

 

7 关于N

关于N，就老老实实学习吧！还是免费的。见下面：

Git - Book

补充点其他的：

这几年流行DevOps开发，提出CI/CD（持续集成，持续部署），这种自动化是如何实现的呢？除了利用各种软件暴露的用于主动交互的接口之外，很多软件还提供了回调机制，也就是在整个处理流程上预留一些点，在这些点可以插入用户自己的代码，当整个软件的流程执行到这些点时，如果有用户注册的代码，则会顺便执行用户的代码。通过这种机制，结合接口调用，主被动结合，就可以实现流程自动化。

以Git来讲，主动方式就是我们调用的各种命令，被动方式就是Git提供的hook机制。hook只是一种叫法，原理都是相通的。

举个例子，假设我们在提交代码时，要求代码必须通过编译才行。此时，就可以利用hook实现这一点。Git的hook例子在.git/hooks目录下，有一些以sample结尾的文件

通过名字，大概就能猜出这些hook点。如果不清楚，可以参考官方文档。要使用这里的hook文件，只需要把sample后缀去掉即可。 

我们可以参考这些文件的写法，补充自己的操作。比如这里，修改commit-msg文件，在其中导出环境变量，编译代码，通过后，正常返回，否则，返回1。当我们返回1的时候，表明编译出现了问题，此时，commit操作就会终止，新修改的代码就无法提交到Git管理仓库。

 这里，我们使用交叉编译测试，结果错误发生，commit没有成功，提示source命令无法执行。但是使用系统命令ls可以显示出目录下的文件。

source命令是shell的内置命令，可能与shell本身有关。查看脚本，发现这里设定的是/bin/sh，将其修改为/bin/bash，再次测试，执行成功

 编译成功，且提交成功。

这个例子很简单，也不具备工程实用性。仅为了解原理。对这块感兴趣的，网上有很多资料，也介绍了很多好用的工具，可以按照提示操作，体验一下。