# Git 内部原理

从根本上来讲 Git 是一个内容寻址（content-addressable）文件系统，并在此之上提供了一个版本控制系统的用户界面

## Git 目录

当在一个新目录或已有目录执行 git init 时，Git 会创建一个 .git 目录。 这个目录包含了几乎所有 Git 存储和操作的东西。

```
$ ls -F1 .git
config
description
HEAD # 指向目前被检出的分支
hooks/
info/
objects/ # 存储所有数据内容
refs/ # 存储指向数据（分支、远程仓库和标签等）的提交对象的指针

# 随着 Git 使用，目录下可能还会包含其他内容

index # 暂存区信息
...

# 同样，随着版本的不同，该目录下可能还会包含其他内容

```

## Git Object

Git 是一个内容寻址文件系统，这意味着，Git 的核心部分是一个简单的键值对数据库（key-value data store）。 可以向 Git 仓库中插入任意类型的内容，它会返回一个唯一的 key，通过该键可以在任意时刻再次取回该内容。

_这个 key 一般为一个长度为 40 的 SHA-1 哈希值 —— 一个将待存储的数据外加一个头部信息（header）一起做 SHA-1 校验运算而得的校验和。_

Git 存储内容的方式 —— 一个文件对应一条内容， 以该内容加上特定头部信息一起的 SHA-1 校验和为文件命名

```
$find .git/objects -type f

.git/objects/61/3f5f0f3bf9224ababb22f5d5db9574f29c7a7d
.git/objects/61/b8f2edc772597698bfad430f6c8926ff8eecf6
```

**校验和的前两个字符用于命名子目录，余下的 38 个字符则用作文件名。** 最后，Git 将内容存经 zlib 压缩后，存入入对应地址

一旦将内容存储在了对象数据库中，那么可以通过 `cat-file` 命令从 Git 那里取回数据。

```
$git cat-file -p 613f5f0f3bf9224ababb22f5d5db9574f29c7a7d

# 将会展示 613f5f0f3bf9224ababb22f5d5db9574f29c7a7d 对应的文件内容
# 613f5f0f3bf9224ababb22f5d5db9574f29c7a7d 为一个
```

```
$ git cat-file -t 613f5f0f3bf9224ababb22f5d5db9574f29c7a7d
commit
```

### Git Object Type

Git Object 存在以下几种类型

* blob
* tree
* commit
* tag

### Blob Object

**数据对象（blob object）**，用于存储文件内容。 当 git 添加一个文件，例如 `example_file.txt` 时，git 会创建一个包含文件内容的 blob-object。

### Tree Object

Git 以一种类似于 UNIX 文件系统的方式存储内容，但作了些许简化。 所有内容均以树对象和数据对象的形式存储，其中树对象对应了 UNIX 中的目录项，数据对象则大致上对应了 inodes 或文件内容。

Git 使用 **树对象（tree object）**，解决文件名保存，以及多个文件组织的问题。

一个 tree-object 包含了一条或多条**树对象记录（tree entry）**， 每条记录含有一个指向 blob-object 或者 sub tree-object 的 SHA-1 指针，以及相应的模式、类型、文件名信息。

```
$ git cat-file -p master^{tree}
100644 blob a906cb2a4a904a152e80877d4088654daad0c859      README
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0      lib

$ git cat-file -p 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
100644 blob ec2394f9a74cc49be02a1551d49f179d73943bd2      lib-file.md
```

![Git 的数据内容结构](https://952542764-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LC8fTcxUHnSNwOMbBUs%2Fuploads%2Fgit-blob-9331e915202ce9a29ccfbd1fb7f7eb49eda8abb6%2Fsimple-version-of-the-git-data-model.png?alt=media)

### Commit Object

\*\*提交对象（Commit Object）\*\*包含目录树对象哈希，父提交哈希，作者，提交者，日期和消息。

```
$ git cat-file -p 84979b887f1f551b933f83c62e35763e92802532
tree 8ea9f4a5cf15af8e4918ec418a53fc7eabc4d332
parent 8f29c536730b7909d25cc033a65e8ba7e4cffe7f
author Author Name <author@email.com> 1614089208 +0800
committer Author Name <author@email.com> 1614089208 +0800

commit message
```

![Git 目录下所有可达的对象](https://952542764-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LC8fTcxUHnSNwOMbBUs%2Fuploads%2Fgit-blob-317acbb077a3cddcc0ccec47001b27bcb0a31a0c%2Fthe-content-structure-of-your-current-git-data.png?alt=media)

### Tag Object

**标签对象（tag object）** 非常类似于一个提交对象，它包含一个标签创建者信息、一个日期、一段注释信息，以及一个指针。 主要的区别在于，标签对象通常指向一个提交对象，而不是一个树对象。 它像是一个永不移动的分支引用，永远指向同一个提交对象，只不过给这个提交对象加上一个更友好的名字罢了。

```
$ git tag -a first-commit -m "Tag pointing to first commit"
$ git cat-file -t f793addc4a909bb148a0547178a9ec130f2bf95b
tag
```

```
$ git cat-file -p f793addc4a909bb148a0547178a9ec130f2bf95b
object 7810a8e30b6142d51541655d66d1ad294c908e90
type commit
tag first-commit
tagger Tagger Name <tagger@email.com> 1601974623 +0800

Tag pointing to first commit
```

PS: 标签对象并非必须指向某个提交对象；可以对任意类型的 Git 对象打标签。

## 如何计算 SHA-1

假设某文件内容为 "what is up, doc?"

```js
// Git 首先会以识别出的对象的类型作为开头来构造一个头部信息，本例中是一个“blob”字符串。
const header = `${objectType} ${content.length}\0`; // "blob 16\u0000"
const store = header + content; // "blob 16\u0000what is up, doc?"
const sha1 = computeSha1(store); // "bd9dbf5aae1a3862dd1526723246b20206e5fc37"
```

## Git 引用

在 Git 中，使用一个文件来保存 SHA-1 值，而该文件有一个名字，这种名字被称为“**引用（references，或简写为 refs）**”。 这些文件被存储在 refs 文件目录中.

Git 分支的本质就是 Refs，例如，master 分支。

```
$find .git/refs
.git/refs
.git/refs/heads
.git/refs/heads/master
.git/refs/heads/feature/doSomething
.git/refs/tags
.git/refs/remotes
.git/refs/remotes/origin
.git/refs/remotes/origin/HEAD
.git/refs/remotes/origin/master
.git/refs/remotes/upstream
.git/refs/remotes/upstream/HEAD
.git/refs/remotes/upstream/master
```

![包含分支引用的 Git 目录对象](https://952542764-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LC8fTcxUHnSNwOMbBUs%2Fuploads%2Fgit-blob-3813644025b31efe0a5d1a592f1deff83cd9fc41%2Fgit-directory-objects-with-branch-head-references-included.png?alt=media)

### HEAD 引用

HEAD 文件通常是一个**符号引用（symbolic reference）**，指向目前所在的分支。 所谓符号引用，表示它是一个指向其他引用的指针。

```
$cat .git/head
ref: refs/heads/feature/git-internals
```

在某些罕见的情况下，HEAD 文件可能会包含一个 git 对象的 SHA-1 值。 例如，merge 失败，解决冲突的过程中。

本质上，通过 HEAD 最终的得到的也是一个 git 对象。

### 标签引用

存在两种类型的标签：附注标签和轻量标签。

创建一个轻量标签：

```
$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
```

这就是轻量标签的全部内容，一个固定的引用。

附注标签则更复杂一些。 若要创建一个附注标签，Git 会创建一个标签对象，并记录一个引用来指向该标签对象，而不是直接指向提交对象。

```
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
```

```
$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2
```

```
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
type commit
tag v1.1
tagger Author <author@email.com> Sat May 23 16:48:58 2020 +0800

test tag
```

### 远程引用

如果添加了一个远程版本库并对其执行过推送操作，Git 会记录下最近一次推送操作时每一个分支所对应的值，并保存在 refs/remotes 目录下。 \*\*远程引用（remote reference）\*\*和分支（位于 refs/heads 目录下的引用）之间最主要的区别在于，远程引用是只读的。

## 包文件

每次提交文件，Git 都会用一个全新的对象来存储新的文件内容，就算只是在一个 400 行的文件后面加入一行新内容。

如果 Git 只完整保存其中一个，再保存另一个对象与之前版本的差异内容，岂不更好？

Git 最初向磁盘中存储对象时所使用的格式被称为 \*\*“松散（loose）”\*\*对象格式。 但是，Git 会时不时地将多个这些对象打包成一个称为 **“包文件（packfile）”** 的二进制文件，以节省空间和提高效率。 当版本库中有太多的松散对象，或者手动执行 git gc 命令，或者向远程服务器执行推送时，Git 都会这样做。

Git 打包对象时，会查找命名及大小相近的文件，并只保存文件不同版本之间的差异内容。

打包对象之后原始的版本将以差异方式保存的，这是因为大部分情况下需要快速访问文件的最新版本。

## 引用规范

\*\*引用规范（refspec）\*\*的格式为 `(+)<src>:<dst>`。 `<src>` 代表远程版本库中的引用； `<dst>` 是本地跟踪的远程引用的位置； `+` 号告诉 Git 即使在不能快进的情况下也要（强制）更新引用。

`<src>`和`<dst>` 均支持以表达式表达。

```
$cat .git/config
...

[remote "origin"]
        url = https://github.com/xyy94813/x-note.git
        fetch = +refs/heads/*:refs/remotes/origin/*

...
```

如果想让 Git 每次只拉取远程的 master 分支，而不是所有分支， 可以把（引用规范的）获取那一行修改为只引用该分支：

```
fetch = +refs/heads/master:refs/remotes/origin/master
```

## 传输协议

Git 可以通过两种主要的方式在版本库之间传输数据： “dumb” 协议和 “smart” 协议。

### Dumb 协议

如果正在架设一个基于 HTTP 协议的只读版本库，一般而言这种情况下使用的就是 Dumb 协议。 这个协议之所以被称为 “Dumb 协议”，是因为在传输过程中，服务端不需要有针对 Git 特有的代码； 抓取过程是一系列 HTTP 的 GET 请求，这种情况下，客户端可以推断出服务端 Git 仓库的布局。

Dumb 协议步骤：

1. 获取服务器端 info/refs
2. 基于 info/refs，检出对应的 ref，一般包含一个 Tree-Object 和一个 Blob-Object
3. 获取对象信息，
   1. 如果服务器端存在，从服务器端获取；
   2. 否则，检查所有替代版本库。如果派生项目存在，从派生项目获取；
   3. 如果替代版本库找不到该对象，检查服务端有哪些可用的包文件，从包文件中查找对象信息
4. 重复步骤 3，直到获取完所有所需的目录信息

Dumb 协议虽然很简单但效率略低，且它不能从客户端向服务端发送数据。

### Smart 协议

智能协议是更常用的传送数据的方法，但它需要在服务端运行一个进程，而这也是 Git 的智能之处 —— 它可以读取本地数据，理解客户端有什么和需要什么，并为它生成合适的包文件。 总共有两组进程用于传输数据，它们分别负责上传和下载数据。

#### 上传数据，通过 SSH

为了上传数据至远端，Git 使用 `send-pack` 和 `receive-pack` 进程。

运行在客户端上的 `send-pack` 进程连接到远端运行的 `receive-pack` 进程。

Git 运行 `send-pack` 进程，通过 SSH 连接 Git 服务器，然后在服务端执行命令。

类似于：

```
$ ssh -x git@server "git-receive-pack 'simplegit-progit.git'"
00a5ca82a6dff817ec66f4437202690a93763949 refs/heads/master report-status \
	delete-refs side-band-64k quiet ofs-delta \
	agent=git/2:2.1.1+github-607-gfba4028 delete-refs
0000
```

#### 上传数据，通过 HTTP

上传过程在 HTTP 上，与 SSH 几乎是相同的，除了握手阶段有一点小区别。 连接是从下面这个请求开始的：

```
=> GET http://server/simplegit-progit.git/info/refs?service=git-receive-pack
001f# service=git-receive-pack
00ab6c5f0e45abd7832bf23074a333f739977c9e8188 refs/heads/master report-status \
	delete-refs side-band-64k quiet ofs-delta \
	agent=git/2:2.1.1~vmg-bitmaps-bugaloo-608-g116744e
0000
```

接下来客户端发起另一个请求，这次是一个 POST 请求，这个请求中包含了 `send-pack` 提供的数据。

```
=> POST http://server/simplegit-progit.git/git-receive-pack
```

这个 POST 请求的内容是 `send-pack` 的输出和相应的包文件。 服务端在收到请求后相应地作出成功或失败的 HTTP 响应。

#### 下载数据，通过 SSH

客户端启动 `fetch-pack` 进程，连接至远端的 `upload-pack` 进程，以协商后续传输的数据。

如果通过 SSH 使用抓取功能，fetch-pack 会像这样运行：

```
$ ssh -x git@server "git-upload-pack 'simplegit-progit.git'"
```

在 `fetch-pack` 连接后，`upload-pack` 会返回类似下面的内容：

```
00dfca82a6dff817ec66f44342007202690a93763949 HEAD multi_ack thin-pack \
	side-band side-band-64k ofs-delta shallow no-progress include-tag \
	multi_ack_detailed symref=HEAD:refs/heads/master \
	agent=git/2:2.1.1+github-607-gfba4028
003fe2409a098dc3e53539a9028a94b6224db9d6a6b6 refs/heads/master
0000
```

这与 `receive-pack` 的响应很相似，但是这里还包含 `HEAD` 引用所指向内容`（symref=HEAD:refs/heads/master）`， 这样如果客户端执行的是克隆，它就会知道要检出什么。

#### 下载数据，通过 HTTP

抓取操作的握手需要两个 HTTP 请求。 第一个是向和 Dumb 协议中相同的端点发送 GET 请求：

```
=> GET $GIT_URL/info/refs?service=git-upload-pack
001e# service=git-upload-pack
00e7ca82a6dff817ec66f44342007202690a93763949 HEAD multi_ack thin-pack \
	side-band side-band-64k ofs-delta shallow no-progress include-tag \
	multi_ack_detailed no-done symref=HEAD:refs/heads/master \
	agent=git/2:2.1.1+github-607-gfba4028
003fca82a6dff817ec66f44342007202690a93763949 refs/heads/master
0000
```

这和通过 SSH 使用 `git-upload-pack` 是非常相似的，但是第二个数据交换则是一个单独的请求：

```
=> POST $GIT_URL/git-upload-pack HTTP/1.0
0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7
0032have 441b40d833fdfa93eb2908e52742248faf0ee993
0000
```

## 维护与数据恢复

有的时候，需要对仓库进行清理 —— 使它的结构变得更紧凑，或是对导入的仓库进行清理，或是恢复丢失的内容。

### 维护

Git 会不定时地自动运行一个叫做 `auto gc` 的命令。 如果有太多松散对象（不在包文件中的对象）或者太多包文件，Git 会运行一个完整的 `git gc` 命令。

这个命令会做以下事情：

* 收集所有松散对象并将它们放置到包文件中， 将多个包文件合并为一个大的包文件，移除与任何提交都不相关的陈旧对象。
* 打包引用到一个单独的文件

大约需要 7000 个以上的松散对象或超过 50 个的包文件才能让 Git 启动一次真正的 gc 命令。 可以通过修改 `gc.auto` 与 `gc.autopacklimit` 的设置来改动这些数值。

如果更新了引用，Git 并不会修改这个文件，而是向 `refs/heads` 创建一个新的文件。 为了获得指定引用的正确 SHA-1 值，Git 会首先在 `refs` 目录中查找指定的引用，然后再到 `packed-refs` 文件中查找。

### 数据恢复

Git 会默默地记录每一次改变 HEAD 时它的值。 每一次提交或改变分支，引用日志都会被更新。 可以通过 `git reflog` 找回丢失的提交信息。

如果引用日志信息也丢失

可以通过 `git fsck --full` 显示出所有没有被其他对象指向的对象，从而找到丢失的 commit。

### 移除对象

git clone 会下载整个项目的历史，包括每一个文件的每一个版本。 然而，如果某个人在之前向项目添加了一个大小特别大的文件，即使将这个文件从项目中移除了，每次克隆还是都要强制的下载这个大文件。 之所以会产生这个问题，是因为这个文件在历史中是存在的，它会永远在那里。

**所以，Git 项目执行 CI 时，可以考虑只获取最新的历史，gitlab ci 就提供了这样的功能。**

## 环境变量

Git 总是在一个 bash shell 中运行，并借助一些 shell 环境变量来决定它的运行方式。

具体环境变量参考：[Git 内部原理 - 环境变量](https://git-scm.com/book/zh/v2/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-%E7%8E%AF%E5%A2%83%E5%8F%98%E9%87%8F)
