Git 如何存储数据的

Git 如何存储数据的.md

Git 使我们每天使用得最多的工具之一，它是 linux 内核的最早作者 Linus Torvalds 创建的全新版本控制工具，和 linux 一样的简单好用，这篇文章就简单地讲一下 git 是如何工作的

要求

• 知道 Git
• 摘要算法的作用（MD5、sha-1
• 一些简单的 Linux 命令

你将了解

• .git 目录结构
• git 如何存储文件

Demo 中用到的工具

• VS Code：一款通用编辑器
• iTerm：macOS 上的命令行软件
• watch：类 Unix 上的命令行工具，可以定时重复执行指定命令并输出
• tree：类 Unix 上的命令行工具，可以输出指定目录的目录树结构

本地配置

1. 在本地安装 Git

https://git-scm.com/下载安装即可

2. 先在任意位置创建一个空文件夹

我在我的桌面上创建了一个名为 git_demo 的文件夹

3. 在命令行中切换到该目录下

4. 监控目录变化

我这里是直接拆分窗口，便于显示，并导航到同样的目录

在右侧窗口中，输入以下命令，用来监控目录变化

watch -d -n 1 tree --charset=ascii -aF

该命令综合了两个工具，一个是watch一个是tree，通过 watch 来定时（上面指定每隔 1 秒）执行一次后面的命令，我们就能够看到实时的目录变化了

补上一个动图版本

开始 Demo

1. Git init

在左侧命令行中执行熟悉的git init，我们将在当前目录创建一个本地的 git 仓库，执行完后是这样的

在右侧我们可以看到，本地多出了一个名为.git的隐藏目录，里面有一些文件夹，我们先看第一级

`-- .git/
    |-- HEAD
    |-- config
    |-- description
    |-- hooks/
    |-- info/
    |-- objects/
    `-- refs/

其中有这么几个文件/夹

• HEAD 他的内容是

  ref: refs/heads/master
  

  说明现在的引用指向的是refs/heads/master这个目录，其实也是我们当前工作的位置

• config 其实就是本地的 git config

  [core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
  

  是一种类toml的数据格式

• description 就是一个描述，平时用不到

  Unnamed repository; edit this file 'description' to name the repository.
  

• hooks 这里存放本地的 git hooks

  他的作用就是在你执行一些特定 git 命令（比如 git commit）的时候，顺带执行你指定的 bash 命令，很强大的功能。比如我们想在提交前执行代码测试，我们就可以去编辑 hooks 里面的pre-commit.sample这个文件，并且去掉文件名末尾的.sample，那在你下次执行git commit的时候，就会先运行这个 bash，只有当整个 bash 执行成功后（退出码为 0），才会执行你刚才的git commit.

• info 存放一些默认的配置文件

  默认的已经存放了一个名为exclude的文件，其实就是一个.gitignore文件

• objects 这里真实地存放着我们代码的备份，一会儿会详细说明的
• refs 这个也是非常关键的一个文件夹，存放着我们所有的分支信息

这个文件夹内，最重要的就是HEAD文件，objects文件夹，refs文件夹，git 通过先访问HEAD文件，找到我们当前工作的分支，然后再去refs文件夹中找到对应的分支描述，这个描述文件正是指向了objects文件夹内的某一个文件，再通过这个文件，我们就能得到当前分支当前版本的所有源码了！

上面看了，HEAD文件其实就只有一行，指向了refs目录的一个文件

我们就来探秘一下refs文件夹和objects文件夹到底是在做什么

2. 新建一个文件

为了避免过多的文件影响，我们先将 hooks 文件夹里的文件都删掉，只保留 pre-commit.sample

现在我们在git_demo目录下新建一个文件名为foo.txt，并且在里面输入以下数据并保存（注意下面的文本结尾没有空格，没有换行）

this is foo

再查看我们的目录结构

|-- .git/
|   |-- HEAD
|   |-- config
|   |-- description
|   |-- hooks/
|   |   `-- pre-commit.sample*
|   |-- info/
|   |   `-- exclude
|   |-- objects/
|   |   |-- info/
|   |   `-- pack/
|   `-- refs/
|       |-- heads/
|       `-- tags/
`-- foo.txt

如期地多出了一个foo.txt文件

3. 将文件添加进缓存区

其实就是我们无比熟悉的git add命令了，我们在左侧命令行执行git add foo.txt，可以看到目录树是这样

|-- .git/
|   |-- HEAD
|   |-- config
|   |-- description
|   |-- hooks/
|   |   `-- pre-commit.sample*
|   |-- index
|   |-- info/
|   |   `-- exclude
|   |-- objects/
|   |   |-- 9b/
|   |   |   `-- 3a97dafadb12faf10cf1a1f3a32f63eaa7220a
|   |   |-- info/
|   |   `-- pack/
|   `-- refs/
|       |-- heads/
|       `-- tags/
`-- foo.txt

在objects文件夹中，多出了一个名为9b的文件夹，并且里面有一个名为3a97dafadb12faf10cf1a1f3a32f63eaa7220a的文件，我们看看这个文件是什么呢

看起来是个二进制文件，其实这个就是我们的源码了，只是被压缩处理了

git 对每次添加进缓存区的文件，都会执行一次 defete 压缩然后存储

我们执行一下这个命令，这个命令的功能是将blob 12\0this is foo这个字符串，用 openssl 中的 sha1 算法计算摘要

echo "blob 12\0this is foo" | openssl sha1

发现了什么，生成的摘要结果（9b3a97dafadb12faf10cf1a1f3a32f63eaa7220a）和我们目录（9b）以及文件名（3a97dafadb12faf10cf1a1f3a32f63eaa7220a）加起来的字符串一样

git 会将文件以 blob 文件长度（单位B）\0文件内容进行计算 sha1，将得到的结果，前两位作为文件夹名称，剩下的部分作为文件名，将我们的文件存储在 objects目录下

好了，我们基本知道了，git 是如何存储我们的文件了，那我们提交一次代码，看会有什么变化

4. git 内置二进制查看工具

我们也可以使用 git 内置的一个查看命令，来查看对应的提交文件

# 查看 object 的类型
> git cat-file -t 9b3a97dafadb12faf10cf1a1f3a32f63eaa7220a
blob
# 查看 object 的类型，后面的提交 hash 其实可以简写前面一部分，只要保证只能检索出一个文件即可
> git cat-file -t 9b3a
blob
# 查看 object 的内容
> git cat-file -p 9b3a
this is foo

5. 进行一次 commit

很常规，我们就执行git commit -m "add foo.txt"这个命令进行提交就好了，结果如下

|-- .git/
|   |-- COMMIT_EDITMSG
|   |-- HEAD
|   |-- config
|   |-- description
|   |-- hooks/
|   |   `-- pre-commit.sample*
|   |-- index
|   |-- info/
|   |   `-- exclude
|   |-- logs/
|   |   |-- HEAD
|   |   `-- refs/
|   |       `-- heads/
|   |           `-- master
|   |-- objects/
|   |   |-- 82/
|   |   |   `-- be13e5bf9fafe4db5ad38c76a5c0116e156953
|   |   |-- 9b/
|   |   |   `-- 3a97dafadb12faf10cf1a1f3a32f63eaa7220a
|   |   |-- f8/
|   |   |   `-- aa85021bfe8c10d9517e22feda4fc67d0a4095
|   |   |-- info/
|   |   `-- pack/
|   `-- refs/
|       |-- heads/
|       |   `-- master
|       `-- tags/
`-- foo.txt

文件夹瞬间多了几个文件，objects 目录中多出了两个文件夹82、f8以及相应的文件，refs文件夹中则是多出了一个名为master的文件，他就是指向我们当前的分支啦

查看一下refs/headers/master文件里面内容是什么

> cat .git/refs/heads/master
82be13e5bf9fafe4db5ad38c76a5c0116e156953

是一个 hash，根据这个hash，我们能够在objects中找到对应的文件了，使用git cat-file查看一下

> git cat-file -t 82be13e5bf9fafe4db5ad38c76a5c0116e156953
commit
> git cat-file -p 82be13e5bf9fafe4db5ad38c76a5c0116e156953
tree f8aa85021bfe8c10d9517e22feda4fc67d0a4095
author Aiello  1577369635 +0800
committer Aiello  1577369635 +0800

add foo.txt

说明这个文件是一个commit类型的文件，文件内容则是指向了一个类型为tree的文件，我们继续顺藤摸瓜，去找这个tree类型的文件包含了什么信息

> git cat-file -t f8aa85021bfe8c10d9517e22feda4fc67d0a4095
tree
> git cat-file -p f8aa85021bfe8c10d9517e22feda4fc67d0a4095
100644 blob 9b3a97dafadb12faf10cf1a1f3a32f63eaa7220a foo.txt

可以看到，这个tree类型的文件，指向了我们的源文件，我们通过之前相同的方法进行一次 hash 计算试试

# 获取提交的类型
> git cat-file -t f8aa85021bfe8c10d9517e22feda4fc67d0a4095
tree
# 获取文件内容
> git cat-file tree f8aa85021bfe8c10d9517e22feda4fc67d0a4095
100644 foo.txt�:������
                      ��/c�
# 计算内容的字节数
> git cat-file tree f8aa85021bfe8c10d9517e22feda4fc67d0a4095 | wc -c
35
# 合起来计算
# 按照 类型 字节数\0内容 的公式计算
> (printf "tree %s\0" $(git cat-file tree f8aa85021bfe8c10d9517e22feda4fc67d0a4095 | wc -c); git cat-file tree f8aa85021bfe8c10d9517e22feda4fc67d0a4095) | openssl sha1
f8aa85021bfe8c10d9517e22feda4fc67d0a4095

会发现，和我们输入的 hash 值一样！ 那我们用同样的方法手动计算一下 commit 的 hash 值呢：

> (printf "commit %s\0" $(git cat-file commit 82be13e5bf9fafe4db5ad38c76a5c0116e156953 | wc -c); git cat-file commit 82be13e5bf9fafe4db5ad38c76a5c0116e156953) | openssl sha1
82be13e5bf9fafe4db5ad38c76a5c0116e156953

和预期一样，输出了我们在目录树中看到的 hash 值，所以，在 git 中，始终使用了这套计算公式来计算 hash:

类型 字节数\0内容

6. 修改当前文件并提交

我们修改一下当前的文件，并提交

> cat foo.txt
this is foo
and new line

执行git add后，我们的目录树变成了这样

|-- .git/
|   |-- COMMIT_EDITMSG
|   |-- HEAD
|   |-- config
|   |-- description
|   |-- hooks/
|   |   `-- pre-commit.sample*
|   |-- index
|   |-- info/
|   |   `-- exclude
|   |-- logs/
|   |   |-- HEAD
|   |   `-- refs/
|   |       `-- heads/
|   |           `-- master
|   |-- objects/
|   |   |-- 82/
|   |   |   `-- be13e5bf9fafe4db5ad38c76a5c0116e156953
|   |   |-- 9b/
|   |   |   `-- 3a97dafadb12faf10cf1a1f3a32f63eaa7220a
|   |   |-- c9/
|   |   |   `-- da32f4e76824497d02312e46ac0a40e28bef91
|   |   |-- f8/
|   |   |   `-- aa85021bfe8c10d9517e22feda4fc67d0a4095
|   |   |-- info/
|   |   `-- pack/
|   `-- refs/
|       |-- heads/
|       |   `-- master
|       `-- tags/
`-- foo.txt

多出了一个名为c9的文件夹，以及相关文件，其实我们用git cat-file就可以看到，这个就是我们当前的文件

> git cat-file -p c9da32f4e768
this is foo
and new line

这说明，git 根据我们的最新文件，又创建了一个新的压缩记录。这个压缩文件中是全量的 foo.txt，就算删掉之前的9b3a97dafadb12faf10cf1a1f3a32f63eaa7220a文件，对当前的文件也是没有任何影响的，我们依然能够获得最新版的全量文件！只是删除以前的记录后，回滚就会出现问题。

接着我们提交这个改动

> git commit -m "update foo.txt"
[master 432a5d9] update foo.txt
 1 file changed, 1 insertion(+)

然后看我们的目录树

|-- .git/
|   |-- COMMIT_EDITMSG
|   |-- HEAD
|   |-- config
|   |-- description
|   |-- hooks/
|   |   `-- pre-commit.sample*
|   |-- index
|   |-- info/
|   |   `-- exclude
|   |-- logs/
|   |   |-- HEAD
|   |   `-- refs/
|   |       `-- heads/
|   |           `-- master
|   |-- objects/
|   |   |-- 03/
|   |   |   `-- 7b10984589cbfe8c6a9c5b84d61592f84fd97a
|   |   |-- 43/
|   |   |   `-- 2a5d918414362c78da50274a1fa0c57b5dc380
|   |   |-- 82/
|   |   |   `-- be13e5bf9fafe4db5ad38c76a5c0116e156953
|   |   |-- 9b/
|   |   |   `-- 3a97dafadb12faf10cf1a1f3a32f63eaa7220a
|   |   |-- c9/
|   |   |   `-- da32f4e76824497d02312e46ac0a40e28bef91
|   |   |-- f8/
|   |   |   `-- aa85021bfe8c10d9517e22feda4fc67d0a4095
|   |   |-- info/
|   |   `-- pack/
|   `-- refs/
|       |-- heads/
|       |   `-- master
|       `-- tags/
`-- foo.txt

和预期的一样，生成了43和03文件夹，分别存放了这次的commit记录和tree记录

> git cat-file -t 432a
commit
> git cat-file -t 037b
tree

7. 提前总结

根据上面的一些操作，我们对 git 的整套存储机制已经有了非常清晰的了解，我们可以大胆的画出下面这个模型图

注意：图中我并没有写出每个文件的hash，但是要知道，每个层中的每个文件都有唯一的一个 hash 作为文件名，所以永远不会存在两个内容相同的文件（就算你的commit信息一样，但是其所对应的 tree 和 blob 的 hash 都会是不同的）！

git 中每一级都是很清晰的分层，各司其职，然后通过 hash 把他们链接起来！

从图中我们可以看到，当前我们所在的 HEAD 是指向的master分支，而master分支又指向某一个指定的提交记录add bar.txt，该提交记录又指向提交时的一个文件目录树，这个树则继续指向了当时的文件！

这种存储方式清晰，可靠，扩展性强，在真实文件层，同样内容的文件，只会存储一份（因为 blob hash 的计算只和文件内容相关，所以一个文件修改后提交，会增加一个新的 blob，如果将其修改回来，再提交，并不会创建新的 blob，而是复用之前的，因为他们的内容都是一模一样的，就算文件名不同，但内容完全相同的文件，也会只存储一份！）

8. 分支切换

其实通过图中可以看到，新建或者切换分支，我们要做的仅仅是新建一个 branch 文件，然后将该文件指向我们指定的 commit 即可，就是这么简单可靠。

至于 git 的回滚、rebase、merge 等等操作，现在看起来就清晰很多了吧

9. 打包送的 hooks

文章开头写的，hooks 可以帮我们做很多事情，我们之前还留有一个叫pre-commit.samplehooks 没有删除，我们就将其拿来用一下

(因为该文件中有一些示例，如果你不想清空，那就复制一份该文件，并将其末尾的 .sample 去掉)

> copy .git/hooks/pre-commit.sample .git/hooks/pre-commit

编辑.git/hooks/pre-commit文件，将其清空，并输入下面的代码

#!/bin/sh
echo "this is pre-commit hooks"

则你在下一次提交的时候，控制台会打印出上面的文字，在这里面，可以写上一些 lint 的代码，如果 lint 通过，则允许提交，然后在pre-push这个 hooks 中运行本地测试，通过才允许提交到服务端，等等（之前在做组件库的时候，我们还用 hooks 自增小版本，哈哈哈，非常方便，也不会有小版本失控的情况，因为更新中版本的时候，会手动重置小版本

现在已经有很多库能够帮助你执行 hooks 了，如husky