devbox
在线问答5
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

git 查看commit内容_Git 原理实战

作者：在线问答5 | 2024-08-15 12:08:46

赞

踩

git查看commit区的内容

9484a129a33f0607dd8e6eb9811fc0fe.png

我之前写了一篇文章

吕海涛：深入理解 Git​zhuanlan.zhihu.com

有朋友反馈说太拘泥于细节，缺少具体的例子。今天就从实际操作角度写一下 git 的原理。本文需要跟《深入理解 Git 》一文一起阅读。

首先，我们使用 git init 初始化一个本地项目：

.git 结构

  1. $ mkdir bar
  2. $ cd bar
  3. $ git init
  4. Initialized empty Git repository in ~/bar/.git/

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

  1. $ tree -L 1 .git
  2. .git
  3. ├── HEAD
  4. ├── config
  5. ├── description
  6. ├── hooks
  7. ├── info
  8. ├── objects
  9. └── refs
  10.  
  11. 8 directories, 4 files

.git/HEAD 文件保存当前所在的分支名，刚出始化完成，其内容为 master，也就是说初始化的默认分支就是 master。

.git/config 文件保存项目专有的配置。git 会优先使用这里的配置。比如我个使用 QQ 邮箱，但在开发公司项目的时候需要使用公司邮箱，我可以这样操作：

  1. $ git config user.email haitao@demo.com
  2. $ cat .git/config|grep user -A1
  3. [user]
  4.         email = haitao@demo.com

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

.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/refs 目录下有 heads 和 tags 两个文件夹，分别保存本地的分支和 tag 信息，我在后文会细说。

对象模型

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

  1. $ echo a > a.txt
  2. $ git add a.txt
  3. $ git status
  4. On branch master
  5.  
  6. No commits yet
  7.  
  8. Changes to be committed:
  9.   (use "git rm --cached <file>..." to unstage)
  10.  
  11.         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 命令：

  1. $ git cat-file -t 78981922613b2afb6025042ff6bd878ac1994e85
  2. blob

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

  1. $ git cat-file blob 78981922613b2afb6025042ff6bd878ac1994e85
  2. a

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

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

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

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

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

  1. $ git commit -m 'init a'
  2. [master (root-commit) 2d567a2] init a
  3.  1 file changed, 1 insertion(+)
  4.   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 的内容：

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

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

  1. $ git cat-files -t 2d567a2f0719e7843fde73f0b37bdce259ec0ab4
  2. commit
  3.  
  4. $ git cat-files commit 2d567a2f0719e7843fde73f0b37bdce259ec0ab4
  5. tree 08585692ce06452da6f82ae66b90d98b55536fca
  6. author 吕海涛 <haitao@demo.com> 1563584316 +0800
  7. committer 吕海涛 <haitao@demo.com> 1563584316 +0800
  8.  
  9. init a

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

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

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

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

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

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

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

git 的对象模型如下：

  1. +------+
  2.  HEAD ---> branch --->|commit|<-+
  3.                       +------+  |
  4.                           |-----+ 
  5.                           v
  6.                       +------+
  7.                       | tree |<-+
  8.                       +------+  |
  9.                           |-----+
  10.                           v
  11.                        +----+
  12.                        |blob|
  13.                        +----+

我们再举一个例子说明 tree 引用 tree 以及 commit 引用 commit 的情况。我们创建一个 b 文件：

  1. $ mkdir b
  2. $ echo b > b/b.txt
  3. $ git add b/b.txt
  4. $ git commit -m "init b"

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

  • .git/objects/0b/8f3e1b03cdb99dbd267563db3ceb286ca118f8
  • .git/objects/33/2b63df384f7e4d864a34572cdd7fefe80bf91b
  • .git/objects/61/780798228d17af2d34fce4cfbdf35556832472
  • .git/objects/f8/f7aefc2900a3d737cea9eee45729fd55761e1a 
  1. # 查看最新 commit
  2. $ cat .git/refs/heads/master
  3. 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8
  4.  
  5. # 查看 commit 内容
  6. # commit 保存项目根目录对应的 tree 对象
  7. # 以及上一次 commit
  8. $ git cat-file commit 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8
  9. tree 332b63df384f7e4d864a34572cdd7fefe80bf91b
  10. parent 2d567a2f0719e7843fde73f0b37bdce259ec0ab4
  11. author 吕海涛 <haitao@demo.com> 1563587510 +0800
  12. committer 吕海涛 <haitao@demo.com> 1563587510 +0800
  13.  
  14. init b
  15.  
  16. # 查看项目根目录
  17. # 有一个文件，对应一个 blob
  18. # 有一个目录，对应一个 tree
  19. $ git ls-tree 332b63df384f7e4d864a34572cdd7fefe80bf91b
  20. 100644 blob 78981922613b2afb6025042ff6bd878ac1994e85    a.txt
  21. 040000 tree f8f7aefc2900a3d737cea9eee45729fd55761e1a    b
  22. # 查看子目录内容
  23. # 有一个文件，对应一个 blob
  24. $ git ls-tree f8f7aefc2900a3d737cea9eee45729fd55761e1a
  25. 100644 blob 61780798228d17af2d34fce4cfbdf35556832472    b.txt
  26.  
  27. # 查看 b.txt 内容
  28. $ git cat-file blob 61780798228d17af2d34fce4cfbdf35556832472
  29. b

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

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

大家体会一下暂存区跟 tree 对象的区别。tree 对象是一个层级结构，外层 tree 对象只引用内层 tree 对象，但不保存子目录结构。如果要查看子目录内容，必须逐级遍历。而暂存区则没有这种层级结构。暂存区保存的是文件的全路径和对应的 blob 对象。通过暂存区 git 可以直接查询任意目录下的文件内容。

当我们执行 git checkout master 的时候，git 会清空暂存区，找到 master 分支的最新 commit，再找到对应的 tree，然后逐级遍历，找到所有的 blob，将它们读到暂存区。之后，再根据暂存区生成新的工作目录。

接下来我们讨论一下分支合并的问题。

分支合并

先创建一个 b 分支：

  1. $ git checkout -b b
  2. $ echo c >> b/b.txt
  3. $ git add b/b.txt
  4. $ git commit -m 'update b'

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

  1. $ git checkout master
  2. $ echo c >> a.txt
  3. $ echo d >> b/b.txt
  4. $ git add a.txt b/b.txt
  5. $ git commit -m 'update a'

现在开始合并操作：

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

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

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

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

  1. # 编号 1
  2. $ git cat-file blob 61780798228d17af2d34fce4cfbdf35556832472
  3. b
  4. # 编号 2
  5. $ git cat-file blob c3219ebbfa21b48e6709a82743eb1c6713d42b73
  6. b
  7. d
  8. # 编号 3
  9. $ git cat-file blob 9ddeb5c4846e8d831655fbafc24f9fe331753a77
  10. b
  11. c

从内容上看，编号 2 对应 master 分支最新提交，编号 3 对应 b 分支最新提交。那编号 1 对应什么呢？

大家先执行一个命令：

  1. $ git merge-base master  b
  2. 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 操作。执行后暂存区变成了这样：

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

好了，只有编号为 0 的版本了。这个时候执行 git commit 就会生成一个新和合并 commit。

到这里，基本的本地操作就分析完了。还有个高级命令需要讲一下，那就是 git reset。

git reset 是把当前分支强制回退到某个版本，其实质就是修改当前分支对应的 .git/refs/head/ 文件内容，并没有什么魔法。

大家如果再看一下 .git 文件夹，会发现多了一个 .git/logs，打开 master 对应的 log：

  1. $ cat .git/logs/refs/heads/master
  2. 0000000000000000000000000000000000000000 2d567a2f0719e7843fde73f0b37bdce259ec0ab4 吕海涛 <haitao@demo.com> 1563584316 +0800   commit (initial): init a
  3. 2d567a2f0719e7843fde73f0b37bdce259ec0ab4 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8 吕海涛 <haitao@demo.com> 1563587510 +0800   commit: init b
  4. 0b8f3e1b03cdb99dbd267563db3ceb286ca118f8 3299494dd317ac03909bccde107324c4cfdf035f 吕海涛 <haitao@demo.com> 1563592597 +0800   commit: update a
  5. 3299494dd317ac03909bccde107324c4cfdf035f e9b225f769b9a9593fc8972d24362001da39228b 吕海涛 <haitao@demo.com> 1563598305 +0800   commit (merge): Merge branch 'b'

里面按时间顺序记录了你在 master 上的所有变更操作。这些日志只会保存在本地，不会推到远端仓库，也无法跟别人共享。git reflog则会将 .git/logs 的内容做一下整理再输出给用户：

  1. $ git reflog
  2. e9b225f (HEAD -> master) HEAD@{0}: commit (merge): Merge branch 'b'
  3. 3299494 HEAD@{1}: commit: update a
  4. 0b8f3e1 HEAD@{2}: checkout: moving from b to master
  5. b408c29 (b) HEAD@{3}: commit: update b
  6. 0b8f3e1 HEAD@{4}: checkout: moving from master to b
  7. 0b8f3e1 HEAD@{5}: checkout: moving from b to master
  8. 2d567a2 HEAD@{6}: checkout: moving from master to b
  9. 0b8f3e1 HEAD@{7}: commit: init b
  10. 2d567a2 HEAD@{8}: checkout: moving from b to master
  11. 2d567a2 HEAD@{9}: checkout: moving from master to b
  12. 2d567a2 HEAD@{10}: commit (initial): init a

git reflog 号称是 git 的时光机。你在本地的所有变更都会记录，你可以通过 git reset 随时随地撤销任意操作。自从知道了 git reflog 这个命令，我再也不单心把本地代码改乱了。

最后讲一下 git 的远程仓库。

pull/push

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

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

先做一点准备工作：

  1. $ mkdir /tmp/bar.git
  2. $ cd /tmp/bar.git
  3. $ git init --bare
  4. Initialized empty Git repository in /tmp/bar.git/
  5. $ ls /tmp/bar.git
  6. HEAD        config      description hooks       info        objects     refs

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

现在我们添加 remote：

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

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

$ git remote rename origin bar

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

  1. $ git push
  2. fatal: No configured push destination.
  3. Either specify the URL from the command-line or configure a remote repository using
  4.  
  5.     git remote add <name> <url>
  6.  
  7. and then push using the remote name
  8.  
  9.     git push <name>
  10.  
  11. $ git push bar
  12. Everything up-to-date

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

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

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

  1. tree .git/refs
  2. .git/refs
  3. ├── heads
  4. │   ├── b
  5. │   └── master
  6. ├── remotes
  7. │   └── bar
  8. │       └── master
  9. └── tags
  10.  
  11. 4 directories, 3 files

因为我们只推了 master 分支，所以 remotes 下面也只有一个 master 文件。除此之外，远端分支跟本地分支就没有什么区别了。如果你有个分支要合并远端的 master 分支，你可以直接执行 git merge bar/master。仅仅是引用名称不同罢了。

而我们常用的 git push 就是将本地的 objects 和 .git/refs/head 的内容同步到远端，对应的反向操作是 git fetch。

就说这些吧，希望对大家有所启发。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/在线问答5/article/detail/983509
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号