Git内部原理

Git是一个快速，可扩展的分布式版本控制系统。从根本上来说，Git是一个内容寻址（content-addressable）文件系统。

Git提供了非常丰富的指令集，根据功能划分为底层命令和高层命令，平时工作中使用最多的add、commit、reset等就属于高层命令。大部分情况下我们不会接触到Git的底层命令，但是为了了解Git的工作原理，了解底层命令就很重要了。

接下来我们来探索Git的内部工作原理

.git目录结构

首先我们新建一个空文件夹，执行git init初始化命令，创建git版本库。

$ mkdir test1
$ cd test1
$ git init
$ cd .git
$ ls -F1

.git目录结构如下：
HEAD         // HEAD指针，指向当前分支
branches/    // 分支
config       // 项目特有的配置选项
description  // 仅供 GitWeb 程序使用，无需关心
hooks/       // 客户端或服务端的钩子脚本
info/        
objects/     // 存储所有数据内容
refs/        // 存储指向数据（分支）的提交对象的指针
index        // 保存暂存区信息（尚待创建）

.git的目录结构及作用上面已经添加了备注，其中有四个条目很重要：HEAD文件、尚未创建的index文件，和objects目录、refs目录。这些条目是Git的核心组成部分。

Git对象

Git一共有四种类型的对象：

  • Blob object
  • Commit object
  • Tree object
  • Tag object

Blob对象存储：

  • 数据内容（文本文件、源代码、图片等）

Commit对象存储：

  • tree对象
  • parent指针（如果有）
  • 作者对象（姓名、邮箱、提交时间）
  • 提交者对象（姓名、邮箱、提交时间）

Tree对象存储：

  • 指向数据内容或者Tree对象的指针（SHA-1）
  • 模式
  • 类型
  • 文件名

Tag对象一般是Commit对象

Tree对象对应文件目录，blob对象对应文件，commit对象对应当前分支的快照（snapshot）

执行git add和git commit时发生了什么？

上面已经创建一个test1的空目录，接下来我们添加一个文件到test1目录。

echo 'hello' > test.txt

执行git status命令，可以看到目录下多了个未跟踪的文件test.txt，这时候执行git add命令，观察.git目录有什么变化。

git add test.txt

cd .git
→ tree
.
├── HEAD
├── branches
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── objects
│   ├── ce
│   │   └── 013625030ba8dba906f756967f9e9ca394464a
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

10 directories, 17 files

可以看到，执行git add命令后，.git/object/目录下新增了一个目录和一个文件（其实是一个40位哈希值，前两位是目录名，后38位是文件名），其实只是多出了一个blob对象，同时创建了一个index文件。后面我们会讲解这个新增的blob对象以及index文件是如何生成的。

我们接着执行git commit命令，看看会发生什么。

→ tree
.
├── COMMIT_EDITMSG
├── HEAD
├── branches
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── logs
│   ├── HEAD
│   └── refs
│       └── heads
│           └── master
├── objects
│   ├── 2b
│   │   └── f705f913222f2032e114e609dfe7f2e97f23bd
│   ├── 92
│   │   └── 0512d27e4df0c79ca4a929bc5d4254b3d05c4c
│   ├── ce
│   │   └── 013625030ba8dba906f756967f9e9ca394464a
│   ├── info
│   └── pack
└── refs
    ├── heads
    │   └── master
    └── tags

15 directories, 23 files

观察控制台的输出可以看到，commit之后多出了5个目录和5个文件，我们只关注objects/目录和refs/目录。执行commit之后，objects目录下新增了两个对象，同时refs/heads/目录下新增了一个master文件。

总结一下，执行git add和git commit命令，objects目录下新增了3个对象，新增了一个index文件和master文件。

这些对象和文件是如何产生的呢，下面我们通过git的底层命令来复盘上面的操作。

使用Git底层命令演示git add和git commit的原理

下面我们新建一个空目录test2，并执行git init命令

mkdir test2
cd test2
git init

使用git has-object往Git数据库写入内容

echo 'hello' | git hash-object -w --stdin
ce013625030ba8dba906f756967f9e9ca394464a

可以看到，控制台输出了一个40位的哈希值，与上面对比发现是一样的。为什么是一样的呢？因为Git是通过头部信息（header）+数据内容（content）通过SHA-1检验计算校验和生成的。

执行完has-object命令后，观察objects/目录的变化，我们用find命令来查看

→ find .git/objects -type f
.git/objects/ce/013625030ba8dba906f756967f9e9ca394464a

可以看到object/目录下多了一个对象，正是我们刚刚写进Git数据后返回的哈希值。

Git数据库是一个简单的key-value data store，哈希值作为key，数据内容作为value。我们可以通过cat-file命令查看这个key对应的内容以及类型。

→ git cat-file -p ce013625030ba8dba906f756967f9e9ca394464a
hello
→ git cat-file -t ce013625030ba8dba906f756967f9e9ca394464a
blob

可以看到，输出的内容正是我们之前写入的，类型是blob类型。

接着我们执行git status命令看看发生了什么

→ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

这里有一个问题，我们之前仅仅保存了文件内容，并没有指定文件名。我们使用tree命令，查看.git目录，可以发现，index文件还没有被创建。

下面我们使用update-index命令来创建一个暂存区，并为之前写入的文件内容指定一个文件名。

git update-index --add --cacheinfo 100644 ce013625030ba8dba906f756967f9e9ca394464a test.txt

再次使用tree命令查看

→ tree .git
.git
├── HEAD
├── branches
├── config
├── description
├── hooks
│   ├── applypatch-msg.sample
│   ├── commit-msg.sample
│   ├── fsmonitor-watchman.sample
│   ├── post-update.sample
│   ├── pre-applypatch.sample
│   ├── pre-commit.sample
│   ├── pre-push.sample
│   ├── pre-rebase.sample
│   ├── pre-receive.sample
│   ├── prepare-commit-msg.sample
│   └── update.sample
├── index
├── info
│   └── exclude
├── objects
│   ├── ce
│   │   └── 013625030ba8dba906f756967f9e9ca394464a
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

10 directories, 17 files

可以发现index文件被创建出来了。这个时候，再次执行git status

→ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   test.txt

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    test.txt

可以发现，test.txt文件已经加入暂存区了，下面还有一个标记为删除的test.txt，为什么呢？
因为我们本地没有test.txt文件，而暂存区有这个文件，使用git status的时候是对比工作目录和暂存区的文件。

如果介意这个deleted的log，可以已通过git checkout -- test.txt命令让暂存区的文件覆盖工作区的文件，我们先不管。

执行git add的时候，除了上面两步，还有一步是将文件写入一个树对象。可以通过git write-tree命令来完成

git write-tree ce013625030ba8dba906f756967f9e9ca394464a
920512d27e4df0c79ca4a929bc5d4254b3d05c4c

执行完后发现，输出了一个40位的哈希值，与上面git add之后对比，可以发现是同一个哈希值。
我们验证下这个对象的类型：

→ git cat-file -t 920512d27e4df0c79ca4a929bc5d4254b3d05c4c
tree

可以发现这确实是个树对象。

至此，我们使用底层命令完成了git add所做的工作。git add的时候做什么，我们可以总结下：

  1. 将文件内容写入Git数据库
  2. 更新暂存区并指定文件名，如果是首次提交到暂存区则是创建暂存区（对应.git目录下的index文件）
  3. 将文件写入树对象

到这里我们还没有提交对象，是时候创建一次提交了。我们可以使用commit-tree命令创建一次提交。

→ echo 'first commit' | git commit-tree 9205
c4cf32be0098f786df455e3fee67ba21779dd70a

可以发现这里输出的哈希值与test1演示项目中的值不同，其他两个都相同，为什么呢？因为commit对象包含时间戳信息，所以计算出来的哈希值肯定是不一样的。

验证下这个对象的类型：

→ git cat-file -t c4cf
commit

可以发现这确实是一个commit对象。

使用git log c4cf命令查看：

commit c4cf32be0098f786df455e3fee67ba21779dd70a
Author: yfm <imyangfm@gmail.com>
Date:   Mon Apr 29 16:30:31 2019 +0800

    first commit

可以看到我们在不使用高层命令的情况下，也完成了一个完整的提交历史。

别高兴的太早，我们我们使用git log命令查看，发现似乎少了点什么东西

→ git log
fatal: your current branch 'master' does not have any commits yet

使用git log命令查看，发现master分支还没有任何提交信息，为什么呢？

对照test1项目，可以发现我们refs/heads目录下还少了个master文件。master文件执行最近一次提交的引用。不可能每次通过哈希值去追溯提交历史，我们可以起个简单的名字方便我们记忆，Git默认的分支名是master，我们就用这个名字代替提交对象的哈希值。

echo 'c4cf32be0098f786df455e3fee67ba21779dd70a' > .git/refs/heads/master

再次运行git log，发现已经与test1项目完全一样了，至此我们使用底层命令完成了git add和git commit所做的所有工作。

git log --pretty=oneline
c4cf32be0098f786df455e3fee67ba21779dd70a (HEAD -> master) first commit

总结下git commit时做了什么：

  1. 创建一个提交对象
  2. 创建一个指向改提交对象的master指针

最后用一张图总结：

版本库

SHA-1检验计算

哈希（hash）使用数据摘要算法（或称散列算法），是信息安全领域中重要的理论基石。该算法将任意长度的输入经过散列运算转换为固定长度输出。固定长度的输出可以称为对应输入内容的数组摘要或哈希值。

前文看到的哪些哈希值是如何计算的呢？

下面内容摘抄自：https://git-scm.com/book/zh/v2/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1

可以通过 irb 命令启动 Ruby 的交互模式：

$ irb
>> content = "what is up, doc?"
=> "what is up, doc?"

Git 以对象类型作为开头来构造一个头部信息，本例中是一个“blob”字符串。 接着 Git 会添加一个空格，随后是数据内容的长度，最后是一个空字节（null byte）：

>> header = "blob #{content.length}\0"
=> "blob 16\u0000"

Git 会将上述头部信息和原始数据拼接起来，并计算出这条新内容的 SHA-1 校验和。 在 Ruby 中可以这样计算 SHA-1 值——先通过 require 命令导入 SHA-1 digest 库，然后对目标字符串调用 Digest::SHA1.hexdigest()：

>> store = header + content
=> "blob 16\u0000what is up, doc?"
>> require 'digest/sha1'
=> true
>> sha1 = Digest::SHA1.hexdigest(store)
=> "bd9dbf5aae1a3862dd1526723246b20206e5fc37"

Git 会通过 zlib 压缩这条新内容。在 Ruby 中可以借助 zlib 库做到这一点。 先导入相应的库，然后对目标内容调用 Zlib::Deflate.deflate()：

>> require 'zlib'
=> true
>> zlib_content = Zlib::Deflate.deflate(store)
=> "x\x9CK\xCA\xC9OR04c(\xCFH,Q\xC8,V(-\xD0QH\xC9O\xB6\a\x00_\x1C\a\x9D"

最后，需要将这条经由 zlib 压缩的内容写入磁盘上的某个对象。 要先确定待写入对象的路径（SHA-1 值的前两个字符作为子目录名称，后 38 个字符则作为子目录内文件的名称）。 如果该子目录不存在，可以通过 Ruby 中的 FileUtils.mkdir_p() 函数来创建它。 接着，通过 File.open() 打开这个文件。最后，对上一步中得到的文件句柄调用 write() 函数，以向目标文件写入之前那条 zlib 压缩过的内容：

>> path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
=> ".git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37"
>> require 'fileutils'
=> true
>> FileUtils.mkdir_p(File.dirname(path))
=> ".git/objects/bd"
>> File.open(path, 'w') { |f| f.write zlib_content }
=> 32

就是这样——你已创建了一个有效的 Git 数据对象。 所有的 Git 对象均以这种方式存储，区别仅在于类型标识——另两种对象类型的头部信息以字符串“commit”或“tree”开头，而不是“blob”。 另外，虽然数据对象的内容几乎可以是任何东西，但提交对象和树对象的内容却有各自固定的格式。

参考

https://git-scm.com/book/zh/v2

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 202,723评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,080评论 2赞 379
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 149,604评论 0赞 335
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,440评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,431评论 5赞 364
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,499评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,893评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,541评论 0赞 256
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,751评论 1赞 296
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,547评论 2赞 319
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,619评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,320评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,890评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,896评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,137评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,796评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,335评论 2赞 342