理解 Git 原理

https://mp.weixin.qq.com/s?__biz=MzIwNjQ5MDk3NA==&mid=2247498671&idx=2&sn=0500b73763a47b0aa2813a1a464b161b&chksm=9722679ea055ee88ca4510234cf15ec39fe6cb870d5f08822fdc22b4f99d806acfaf9e925355&mpshare=1&scene=1&srcid=0403YulSc3z6ECKPcMG1zYOW&sharer_sharetime=1617422663258&sharer_shareid=113038468f1d36b6a239e0eb83b4734c&exportkey=A3EOc31zPJTPLBLhm4lPjRE%3D&pass_ticket=jfQkaMOXwQpWh1nSYZrktUcJiEbpzE6IR3ofLiKJEN%2F4%2FmBDHqt2dn4%2Bn58v%2B3Dz&wx_header=0#rd
—
我们使用 git init 初始化一个本地项目：
.git 结构

$ mkdir bar
$ cd bar
$ git init
Initialized empty Git repository in ~/bar/.git/

显然，git 会在当前目录创建一个 .git 文件夹，目录结构如下：

$ tree -L 1 .git
.git
├── HEAD
├── config
├── description
├── hooks
├── info
├── objects
└── refs

8 directories, 4 files

.git/HEAD 文件保存当前所在的分支名，刚出始化完成，其内容为 master，也就是说初始化的默认分支就是 master。
.git/config 文件保存项目专有的配置。git 会优先使用这里的配置。比如我个使用 QQ 邮箱，但在开发公司项目的时候需要使用公司邮箱，我可以这样操作：

$ git config user.email [email protected]
$ cat .git/config|grep user -A1
[user]
email = [email protected]

一般不需要改动项目配置。

.git/description 文件是给 gitweb 展示用的，大家可以先怱略。
.git/hooks/ 是一些脚本，git 可以在不同的阶段执行一些脚本。如果你想在 git push 之前跑一遍单元测试，你可以把跑单元测试的命令写到 .git/hooks/pre-push 脚本。这些脚本需要具备可执行权限才行。
git 支持的 hook 有很多，但大多不常用，就不再展开讨论了。

.git/objects 目录是 git 的 data object store，用于保存诸如 blob, tree, commit, tag 等对象，我在后文会细说。
对象模型

接下来，我们使用 git add 添加一个文件：

$ echo a > a.txt
$ git add a.txt
$ git status
On branch master

No commits yet

Changes to be committed:
(use “git rm –cached …” to unstage)

new file: a.txt

这个时候我们再看一下 .git 文件夹，你会发现多了两个文件：

.git/index
.git/objects/78/981922613b2afb6025042ff6bd878ac1994e85

先说这 objects 下的这个文件。
git 使用多种对象保存版本信息。每个对象的名字是其本身内容的 sha1 摘要值。sha1 一共 40 位。为了减少磁盘压力，git 取 sha1 的前两位作为目录名，取剩下的 38 位作为文件名。这样，在 .git/objects 下最多会生成 00-ff 256 个文件夹。
所以，当我们执行了 git add a.txt 以后，git 会生成一个名为 78981922613b2afb6025042ff6bd878ac1994e85 的对象。这是个什么对象呢？git 很贴心地为我们提供了 git cat-file 命令：

$ git cat-file -t 78981922613b2afb6025042ff6bd878ac1994e85
blob

原来是个 blob。让我们看一下 blob 的内容：

$ git cat-file blob 78981922613b2afb6025042ff6bd878ac1994e85
a

这就很明显了，这个 blob 保存的正是 a.txt 内容。

所以，只要加到暂存区的文件，git 就会生成对应的 blob 对象。那此时暂存区里有什么内容呢？git 也同样提供了查询命令：

$ git ls-files -s
100644 78981922613b2afb6025042ff6bd878ac1994e85 0 a.txt

显然，最后一列是文件名。第二列是该文件对应的 blob 对象。第一列表示文件的 UNIX 模式，包括权限、类型等信息。第三列是一个神奇的数字，是用来在分支合并的时候处理冲突的，我在下面还会讲。

现在我们可以提交一个版本了。

$ git commit -m ‘init a’
[master (root-commit) 2d567a2] init a
1 file changed, 1 insertion(+)
create mode 100644 a.txt

这时我们再看一下 .git 的内容，你会发现新增了三个文件：

.git/objects/08/585692ce06452da6f82ae66b90d98b55536fca
.git/objects/2d/567a2f0719e7843fde73f0b37bdce259ec0ab4
.git/refs/heads/master

git 在 .git/refs/heads 新建了一个名为 master 的文件。这就是 git 分支的本质。你每创建一个分支，git 就会在 .git/refs/heads 下新建一个同名文件，文件保存该分支最新的 commit 对象 sha1。我们看一下 .git/refs/heads/master 的内容：

$ cat .git/refs/heads/master
2d567a2f0719e7843fde73f0b37bdce259ec0ab4

正好指向了新增加的一个 object。让我们看看这个对象的内容：

$ git cat-files -t 2d567a2f0719e7843fde73f0b37bdce259ec0ab4
commit

$ git cat-files commit 2d567a2f0719e7843fde73f0b37bdce259ec0ab4
tree 08585692ce06452da6f82ae66b90d98b55536fca
author 吕海涛 1563584316 +0800
committer 吕海涛 1563584316 +0800

init a

我们提交的 commit 对象指向了一个名为 08585692ce06452da6f82ae66b90d98b55536fca tree 对象，这就 .git 文件夹新增的另一个文件。

因为 tree 对象含有二进制内容，直接使用 git cat-file 会输出乱码。所以，git 专门提供了一个 git ls-tree 命令：

$ git ls-tree 08585692ce06452da6f82ae66b90d98b55536fca
100644 blob 78981922613b2afb6025042ff6bd878ac1994e85 a.txt

是不是很眼熟？对了，这就是刚才暂存区的内空。

我们再看看 .git/HEAD 的内容：

$ cat .git/HEAD
ref: refs/heads/master

.git/HEAD 保存了当前分支对应的 refs 路径。

git 的对象模型如下：

+——+
HEAD —> branch —>|commit|<-+ +------+ | |-----+ v +------+ | tree |<-+ +------+ | |-----+ v +----+ |blob| +----+ 我们再举一个例子说明 tree 引用 tree 以及 commit 引用 commit 的情况。我们创建一个 b 文件： $ mkdir b $ echo b > b/b.txt
$ git add b/b.txt
$ git commit -m “init b”

这时 .git 目录新增了 4 个文件：

.git/objects/0b/8f3e1b03cdb99dbd267563db3ceb286ca118f8
.git/objects/33/2b63df384f7e4d864a34572cdd7fefe80bf91b
.git/objects/61/780798228d17af2d34fce4cfbdf35556832472
.git/objects/f8/f7aefc2900a3d737cea9eee45729fd55761e1a

# 查看最新 commit
$ cat .git/refs/heads/master
0b8f3e1b03cdb99dbd267563db3ceb286ca118f8

# 查看 commit 内容
# commit 保存项目根目录对应的 tree 对象
# 以及上一次 commit
$ git cat-file commit 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8
tree 332b63df384f7e4d864a34572cdd7fefe80bf91b
parent 2d567a2f0719e7843fde73f0b37bdce259ec0ab4
author 吕海涛 1563587510 +0800
committer 吕海涛 1563587510 +0800

init b

# 查看项目根目录
# 有一个文件，对应一个 blob
# 有一个目录，对应一个 tree
$ git ls-tree 332b63df384f7e4d864a34572cdd7fefe80bf91b
100644 blob 78981922613b2afb6025042ff6bd878ac1994e85 a.txt
040000 tree f8f7aefc2900a3d737cea9eee45729fd55761e1a b
# 查看子目录内容
# 有一个文件，对应一个 blob
$ git ls-tree f8f7aefc2900a3d737cea9eee45729fd55761e1a
100644 blob 61780798228d17af2d34fce4cfbdf35556832472 b.txt

# 查看 b.txt 内容
$ git cat-file blob 61780798228d17af2d34fce4cfbdf35556832472
b

我们再说一下暂存区。当我们提交内容以后，暂存区的内容并没有清空。

$ git ls-files -s
100644 78981922613b2afb6025042ff6bd878ac1994e85 0 a.txt
100644 61780798228d17af2d34fce4cfbdf35556832472 0 b/b.txt

大家体会一下暂存区跟 tree 对象的区别。tree 对象是一个层级结构，外层 tree 对象只引用内层 tree 对象，但不保存子目录结构。如果要查看子目录内容，必须逐级遍历。而暂存区则没有这种层级结构。暂存区保存的是文件的全路径和对应的 blob 对象。通过暂存区 git 可以直接查询任意目录下的文件内容。
当我们执行 git checkout master 的时候，git 会清空暂存区，找到 master 分支的最新 commit，再找到对应的 tree，然后逐级遍历，找到所有的 blob，将它们读到暂存区。之后，再根据暂存区生成新的工作目录。
接下来我们讨论一下分支合并的问题。
分支合并

先创建一个 b 分支：

$ git checkout -b b
$ echo c >> b/b.txt
$ git add b/b.txt
$ git commit -m ‘update b’

再回到 master 分支做一点改动：

$ git checkout master
$ echo c >> a.txt
$ echo d >> b/b.txt
$ git add a.txt b/b.txt
$ git commit -m ‘update a’

现在开始合并操作：

$ git checkout master
$ git merge b
Auto-merging b/b.txt
CONFLICT (content): Merge conflict in b/b.txt
Automatic merge failed; fix conflicts and then commit the result.

好了，有一个冲突。在解决冲突之前，我们先看一下暂存区：

$ git ls-files -s
100644 0f7bc766052a5a0ee28a393d51d2370f96d8ceb8 0 a.txt
100644 61780798228d17af2d34fce4cfbdf35556832472 1 b/b.txt
100644 c3219ebbfa21b48e6709a82743eb1c6713d42b73 2 b/b.txt
100644 9ddeb5c4846e8d831655fbafc24f9fe331753a77 3 b/b.txt

这里面有三个 b/b.txt，分别使用 1/2/3 编号。我们先看看对应的文件内容：

# 编号 1
$ git cat-file blob 61780798228d17af2d34fce4cfbdf35556832472
b
# 编号 2
$ git cat-file blob c3219ebbfa21b48e6709a82743eb1c6713d42b73
b
d
# 编号 3
$ git cat-file blob 9ddeb5c4846e8d831655fbafc24f9fe331753a77
b
c

从内容上看，编号 2 对应 master 分支最新提交，编号 3 对应 b 分支最新提交。那编号 1 对应什么呢？
大家先执行一个命令：

$ git merge-base master b
0b8f3e1b03cdb99dbd267563db3ceb286ca118f8

这个命令的功能是查找 master 分支和 b 分支最新的公共袓先 commit。我们查到的是 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8。这里的编号 1 对应的就是这个 commit 中 b/b.txt 的内容。
git 的合并流程是这样的。首先，将 master 分支的最新 commit 加载到暂存区，统一使用编号 1。然后，将 b 分支的最新 commit 加载到暂存区，统一使用编号 2。再后，遍历暂存区，尝试自动合并，没有冲突的改用编号 0，并移除编号 1 和 2。
对于有冲突的情况，则需要进行三路合并(3-way merge)。这个三路就是三个版本的意思，对我们这个例子来说就是 master 版本、b 版本和它们的最近公共袓先版本。三路合并不是 git 发明的，git 在最早甚至都依赖外部命令进行三路合并。如果没有冲突，则继续更新暂存区；如果有则保留对应文件的编号 1 和编号 2 的 blob。
好了，处理完冲突后要执行 git add 操作。执行后暂存区变成了这样：

git ls-files -s
100644 0f7bc766052a5a0ee28a393d51d2370f96d8ceb8 0 a.txt
100644 dcfa657440d473a5335c09a0d04a7db32d1a062c 0 b/b.txt

好了，只有编号为 0 的版本了。这个时候执行 git commit 就会生成一个新和合并 commit。
到这里，基本的本地操作就分析完了。还有个高级命令需要讲一下，那就是 git reset。
git reset 是把当前分支强制回退到某个版本，其实质就是修改当前分支对应的 .git/refs/head/ 文件内容，并没有什么魔法。
大家如果再看一下 .git 文件夹，会发现多了一个 .git/logs，打开 master 对应的 log：

$ cat .git/logs/refs/heads/master
0000000000000000000000000000000000000000 2d567a2f0719e7843fde73f0b37bdce259ec0ab4 吕海涛 1563584316 +0800 commit (initial): init a
2d567a2f0719e7843fde73f0b37bdce259ec0ab4 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8 吕海涛 1563587510 +0800 commit: init b
0b8f3e1b03cdb99dbd267563db3ceb286ca118f8 3299494dd317ac03909bccde107324c4cfdf035f 吕海涛 1563592597 +0800 commit: update a
3299494dd317ac03909bccde107324c4cfdf035f e9b225f769b9a9593fc8972d24362001da39228b 吕海涛 1563598305 +0800 commit (merge): Merge branch ‘b’

里面按时间顺序记录了你在 master 上的所有变更操作。这些日志只会保存在本地，不会推到远端仓库，也无法跟别人共享。git reflog则会将 .git/logs 的内容做一下整理再输出给用户：
git reflog 号称是 git 的时光机。你在本地的所有变更都会记录，你可以通过 git reset 随时随地撤销任意操作。自从知道了 git reflog 这个命令，我再也不单心把本地代码改乱了。
最后讲一下 git 的远程仓库。
pull/push

我们最常用的命令莫过于 git clone。大家从开始就为远程赋予了特殊的光环，但 git 却对它们一视同仁。

git 的 remote 支持多种协议，包括 ssh, http, file。为演示访便，我们使用 file 协议。

先做一点准备工作：

$ mkdir /tmp/bar.git
$ cd /tmp/bar.git
$ git init –bare
Initialized empty Git repository in /tmp/bar.git/
$ ls /tmp/bar.git
HEAD config description hooks info objects refs

大家注意，我在执行 git init 时加了 —bare 参数，这是告诉 git 不要生成 .git 文件夹。因为我们要生成一个远程仓库。

现在我们添加 remote：

$ git remote add origin file:///tmp/bar.git
$ git push
Enumerating objects: 20, done.
Counting objects: 100% (20/20), done.
Delta compression using up to 4 threads
Compressing objects: 100% (9/9), done.
Writing objects: 100% (20/20), 1.29 KiB | 441.00 KiB/s, done.
Total 20 (delta 1), reused 0 (delta 0)
To file:///tmp/bar.git
* [new branch] master -> master

这里我们用了 origin 这个名字。这是 git 的默认 remote 名字。但 remote 可以叫任何名字的。比如：

$ git remote rename origin bar

只是一旦你改了名字，你在 push 的时候就必须指定名字了：

$ git push
fatal: No configured push destination.
Either specify the URL from the command-line or configure a remote repository using

git remote add

and then push using the remote name

git push

$ git push bar
Everything up-to-date

添加了 remote 之后 git 会更新 .git/config 文件

cat .git/config|grep remote -A 2
[remote “bar”]
url = file:///tmp/bar.git
fetch = +refs/heads/master:refs/remotes/bar/master

而对应的也会在 .git/refs/remotes 创建远端分支的对应文件：

tree .git/refs
.git/refs
├── heads
│ ├── b
│ └── master
├── remotes
│ └── bar
│ └── master
└── tags

4 directories, 3 files

因为我们只推了 master 分支，所以 remotes 下面也只有一个 master 文件。除此之外，远端分支跟本地分支就没有什么区别了。如果你有个分支要合并远端的 master 分支，你可以直接执行 git merge bar/master。仅仅是引用名称不同罢了。
而我们常用的 git push 就是将本地的 objects 和 .git/refs/head 的内容同步到远端，对应的反向操作是 git fetch。
就说这些吧，希望对大家有所启发。