1. Toy模板网首页
  2. > Toy博客

深入剖析 Git 对象底层原理

9月前 作者：归思君 分类：Toy博客 阅读(45) 违法举报

这篇具有很好参考价值的文章主要介绍了深入剖析 Git 对象底层原理。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

一、引言

在我们日常使用 Git 时，通常的操作是：

  • 在写完一段代码后，执行 git add命令，将这段代码添加到暂存区中
  • 然后再执行 git commit和 git push 命令，将 本地 Git 版本库中的提交同步到服务器中的版本库中

Git 在中间做了什么，它如何存储不同的文件和内容，以及如何区分不同分支下的文件版本呢？日常操作对这些自动的操作都是无感的。
但是如果哪天一旦上述操作中出现了错误，需要找回自己的代码时，如果不懂 Git 其内部存储原理，是没法找回的，因此为了避免这种情况，就有必要去了解其内部的存储——Git 对象的原理。

二、Git 对象

2.1. Git 对象概述

我们知道，Git 是一个内容寻址文件系统，其核心部分是一个键值对数据库。
当我们向 Git 仓库中插入任意类型的内容时，它会返回一个唯一的键。我们可以通过该键在任意时刻再次取回插入的内容。
比如我们初始化 GitDemo ，发现 Git 对 objects 目录进行了初始化，并创建了 pack 和 info 子目录，但均为空：

$ git init GitDemo
Initialized empty Git repository in D:/GitDemo/.git/
$ find .git/objects
.git/objects
.git/objects/info
.git/objects/pack
$ find .git/objects -type f

然后创建一个 readme.txt 文本，执行 git add后会发现在 .git/objects 中新增了一个文件夹 89 和文件 dab47ae90ebdfee4e6cb3d64708cd73e9c5472，

$ echo 'read me please' > readme.txt
$ git add readme.txt
$ find .git/objects -type f
.git/objects/89/dab47ae90ebdfee4e6cb3d64708cd73e9c5472

查看其文件内容，类型和大小：

$ git cat-file -p 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472
read me please
$ git cat-file -t 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472
blob
$ git cat-file -s 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472
15

这个键值为 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472的对象就是 Git 对象中的 blob 对象。而且 Git 中所有的对象都存储在 .git/objects目录（也叫做对象库）中。
这个键值是一个 SHA-1 的哈希值，由 40 个十六进制的数字组成。它是通过一个将待存储的数据外加一个头部信息一起做 SHA 算法运算而得到的校验和。40 个十六进制数字就相当于 160 比特，当用 SHA-1 对不同对象进行区分和识别时，冲突的概率就会极低，不用存储文件的具体类型，用 blob 和 SHA-1 就足以分辨不同文件内容了。
下面来看看 Git 对象的类型：

2.2. Git 对象类型

2.2.1. Blob 对象

1. Blob 对象的定义和作用

Blob（Binary Large Object，二进制大对象）是Git中的一种对象类型，用来指代某些可以包含任意数据的变量或文件。它是Git对文件内容的一种抽象表示。每个文件在Git仓库中都被表示为一个独立的Blob对象。Blob对象保存了文件的原始二进制数据，无论文件是文本文件还是二进制文件，Git都以Blob对象的形式存储它们。
比如在上一节中的 readme.txt 文本，在 Git 中就是以 blob 对象存储的：

$ git cat-file -t 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472
blob
$ git cat-file -p 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472
read me please
  • **当在Git仓库中添加、修改或删除某个文件时，Git会创建一个新的Blob对象来存储这个文件的内容。**这样就可以跟踪文件的变化历史，并且可以在需要时恢复到特定的文件版本。

比如我们修改 readme.txt 文本，会发现有两个 blob 对象存储 readme.txt 的两个版本：

//新增一行文本: reading
$ vi readme.txt
$ git add readme.txt
//原来版本的readme.txt内容还存在：
$ git cat-file -p 89dab47ae90ebdfee4e6cb3d64708cd73e9c5472
//新版本的readme.txt内容
$ git cat-file -p b0530c9
read me please
reading
  • 因为在修改内容后创建了新的 Blob 对象，因此 Git 可以使用 Blob 对象来进行文件比较操作。通过比较两个Blob对象的哈希值，Git可以快速确定文件内容是否发生了变化，从而进行版本控制和合并操作。
2. Blob 对象的存储方式

Blob对象在Git中的存储方式是使用对象哈希值来进行索引和存储。具体的存储方式如下：

  1. 当在 Git 仓库中添加文件并执行 git add时，Git 就会提取该内容，然后将内容进行 SHA-1 哈希计算，得到一个40个十六进制字符的哈希值。这个哈希值就是Blob对象的唯一标识符，也就是我们上节提到的键。
  2. 而后如果Blob对象是新的，Git会将它以哈希值（上面由 SHA-1 哈希计算得到的标识符）为文件名存储在对象数据库中(也就是 .git/objects 目录下)。
  3. 存储时，Git将Blob对象的内容写入一个临时文件，并将该文件的路径与哈希值相关联。（一般来说取前两位作为文件目录，剩下的 38 位作为文件名。比如 readme.txt 文件：目录是 89，文件名为 dab47ae90ebdfee4e6cb3d64708cd73e9c5472。）
  4. 此外如果 blob 对象过大，Git会对存储的Blob对象进行压缩，并将压缩后的数据写入真正的对象文件中。这些压缩的文件存储在 .git/objects/pack 中

2.2.2. Tree 对象

1. Tree 对象的定义和作用

Tree 对象是Git中的一种对象类型，用于表示文件和目录的组织结构。每当向Git仓库中添加一个目录时，Git会创建一个新的Tree对象来表示该目录的结构。Tree对象包含了目录中的文件和子目录的元数据，以及它们对应的Blob或Tree对象的哈希值。
比如我们接着在 GitDemo 仓库中添加目录 lib和文件 readme2.txt 并提交后，当前目录为:

│  readme.txt
│
└─lib
      readme2.txt

在 git 中的存储如下：

$ git cat-file -p master^{tree}
040000 tree dbff68a947c7cc60653ff64260b372a405939ae2    lib
100644 blob b0530c9b7360a8cea0e4af86475cac70a2985138    readme.txt

master^{tree} 语法表示 master 分支上最新的提交所指向的树对象。lib 子目录（所对应的那条树对象记录）并不是一个数据对象，而是一个指针，其指向的是另一个树对象：
深入剖析 Git 对象底层原理,重学Git,git,团队开发

$ git cat-file -p dbff68a947c7cc
//模式  对象类型   对象的SHA-1值                          文件名
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    readme2.txt

从上面可以发现，一个 Tree 对象包含一条或多条树对象记录。每条记录含有一个指向数据对象或者子目录对象的 SHA-1 指针，以及相应的模式、类型、对象名(SHA-1 值)、文件名信息：
深入剖析 Git 对象底层原理,重学Git,git,团队开发

  1. 模式（Mode）：模式表示文件或目录的类型和权限。它是一个八进制数字，通常以4位表示。常见的模式包括：
  • 100644：表示普通文件，即Blob对象。
  • 100755：表示可执行文件，即Blob对象。
  • 040000：表示目录，即Tree对象。
  1. 类型（Type）：类型表示列表项所指向的对象类型，即是Blob对象还是Tree对象。
  2. 对象名（Object Name）：对象名是对应的Blob或Tree对象的哈希值。它是一个40个十六进制字符的字符串，用于唯一标识对象。
  3. 文件名或目录名（File/Directory Name）：文件名或目录名是列表项所代表的文件或目录的名称。

如果记录中的类型为 Blob，表示该项是一个文件；如果该类型为 Tree，表示该项是一个子目录。

2. Tree 对象的存储方式

和 blob 对象的存储方式类似，Tree对象在Git中的存储方式是使用对象哈希值来进行索引和存储。当执行 git add 时 Git 内部的操作有：

  1. 构建树对象：当你在Git仓库中添加、修改或删除文件时，Git会根据当前目录结构构建一个Tree对象。该Tree对象包含了目录中的文件和子目录的元数据，以及它们对应的Blob或Tree对象的哈希值。
  2. 哈希计算：Git会对Tree对象的内容进行哈希计算，生成一个40个十六进制字符的哈希值。这个哈希值就是Tree对象的唯一标识符。
  3. 检查存储：Git会检查对象数据库中是否已存在具有相同哈希值的Tree对象。如果存在，则直接引用已有的对象；如果不存在，则进行存储。
  4. 存储对象：如果Tree对象是新的，Git会将它以哈希值为文件名存储在对象数据库中。对象数据库通常位于".git/objects"目录下。存储时，Git将Tree对象的内容以特定的格式写入一个临时文件，并将该文件的路径与哈希值相关联。
  5. 压缩和索引：Git会对存储的Tree对象进行压缩，并将压缩后的数据写入真正的对象文件中。同时，Git会更新索引文件，将Tree对象的哈希值与文件路径进行映射。

2.2.3. Commit 对象

1. Commit 对象的定义和作用

Commit对象是Git中的一种对象类型，用于记录代码仓库中的提交操作（也就是执行 git commit命令）。每个Commit对象代表一个特定的提交操作，包含了提交的元数据和指向代码快照的引用。通过Commit对象，Git能够跟踪代码修改的历史，并实现版本控制和代码回溯等功能。
如下图所示，每个 Commit 对象就是一个 version 版本，Commit 对象通过指向代码快照（也就是一个 Tree 对象）的引用，记录了代码仓库在某个特定时间点的状态。
深入剖析 Git 对象底层原理,重学Git,git,团队开发
我们再次引用上面 Tree 对象中的 GitDemo 仓库案例，此时仓库中有如下文件和目录：

│  readme.txt
│
└─lib
      readme2.txt

可以通过 git cat-file master命令查看此时的 commit 对象：

//master就是一个指向commit对象的指针, 其内部存储Commit对象的SHA-1值
$ cat .git/refs/heads/master
2b2af66549827bd6a466fe43081f406c2a12900b
$ git cat-file -p 2b2af665498
tree 2503e9e0c4f774fc5ce298f4972f0e6d3a800d6f
parent 7b34a1e750918570ed610ee1f228e83b43a1192e
author wangJw <wangJw@163.com> 1705458723 +0800
committer wangJw <wangJw@163.com> 1705458723 +0800

second commit

从上面可知，一个 commit 对象由这样几个部分组成：

  1. 指向代码快照的引用（tree）：Commit对象包含一个指向代码快照的引用，通常是指向一个Tree对象。该Tree对象记录了提交时代码仓库中文件和目录的状态。
  2. 父提交（parent）：Commit对象可以有一个或多个父提交，指向前一个或多个Commit对象。这构成了提交历史的链式结构。通常，一个Commit对象的父提交是它之前的一个Commit对象，除非进行了分支合并等操作。
  3. 作者（author）：Commit对象记录了提交的作者信息，包括姓名和电子邮件。作者是指实际进行代码更改的人。
  4. 提交者（Committer）：Commit对象还包含了提交者信息，通常与作者相同。提交者是指将更改提交到代码仓库的人。
  5. 提交消息（Commit Message）：也就是 second commit 中的内容， Commit对象包含了提交时附加的可选消息，用于描述提交的目的、更改的内容、修复的问题等。提交消息可以提供其他开发者和团队成员了解提交的背景和目的。
  6. Commit对象的哈希值（SHA-1 值）：每个Commit对象都有一个唯一的哈希值，用于标识该对象。

加上 commit 对象和 master 指针，可以完善在 tree 对象中的图：
深入剖析 Git 对象底层原理,重学Git,git,团队开发

2. Commit 对象的存储方式

当执行 git commit命令提交代码时，commit 对象随之创建，Git 的内部操作有：

  1. 内容提取：执行git commit命令提交代码时，Git会提取提交的相关信息，包括作者、提交者、提交时间、提交消息和父提交等。
  2. 创建对象：Git会将提交信息和父提交的引用等数据组合成一个Commit对象。
  3. 哈希计算：Git会对Commit对象的内容进行SHA-1哈希计算，得到一个40个十六进制字符的哈希值。这个哈希值就是Commit对象的唯一标识符。
  4. 检查存储：Git会检查对象数据库中是否已存在具有相同哈希值的Commit对象。如果存在，则直接引用已有的对象；如果不存在，则进行存储。
  5. 存储对象：如果Commit对象是新的，Git会将它以哈希值为文件名存储在对象数据库中。对象数据库通常位于 .git/objects 目录下。存储时，Git将Commit对象的内容写入一个临时文件，并将该文件的路径与哈希值相关联。
  6. 压缩和索引：Git会对存储的Commit对象进行压缩，并将压缩后的数据写入真正的对象文件中。同时，Git会更新索引文件，将Commit对象的哈希值与文件路径进行映射。

2.2.4. Tag 对象

1. Tag 对象的定义和作用

Tag对象是Git中的一种对象类型，用于给特定的提交打上标记。Tag对象的主要作用是标记代码仓库中的特定提交或里程碑。它可以用于记录发布版本、重要的里程碑、稳定的代码快照等。git 标签分为两种类型：轻量标签和附注标签。

轻量标签

轻量标签是指向提交对象的引用：

//创建轻量级标签
$ git tag firstTag
//查看标签：
$ git tag
firstTag

当创建了 firstTag 后，会在.git/refs/tags 目录下创建一个名为 firstTag 的文件，其内容指向当前的 commit 对象的 SHA-1 值

$ cat .git/refs/tags/firstTag
2b2af66549827bd6a466fe43081f406c2a12900b
//轻量标签指向提交对象的引用
$ git cat-file -t firstTag
commit
$ git cat-file -p firstTag
tree 2503e9e0c4f774fc5ce298f4972f0e6d3a800d6f
parent 7b34a1e750918570ed610ee1f228e83b43a1192e
author wangJw <wangJw@163.com> 1705458723 +0800
committer wangJw <wangJw@163.com> 1705458723 +0800

second commit

我们发现，轻量标签 firstTag 中的内容只有一个指向提交对象的 SHA-1 值。没有其他内容，因此无法知道何人，什么时间创建的标签。在团队开发中很容易发生混淆，因此可以用另外一种打标签的方式：附注标签

附注标签

附注标签则是仓库中的一个独立对象，使用带参数 -a 或 -m <msg> 的 git tag 命令：

//创建一个空提交：
$ git commit --allow-empty -m "empty commit for tagTest"
[master 8a4678f] empty commit for tagTest
//创建一个附注标签
$ git tag -m "secondTag" secondTag
//查看所有标签
$ git tag
firstTag
secondTag

这个时候再来看看 .git/refs/tags中的 secondTag 标签内容：

//查看该标签的类型
$ git cat-file -t secondTag
tag
//再来看看secondTag标签的内容
$ git cat-file -p secondTag
object 8a4678fae181c16c6f4ff0e6a618991128d86da2
type commit
tag secondTag
tagger wangJw <wangJw@163.com> 1705480524 +0800

secondTag

主要由这样几个部分组成：

  1. 标签指向的提交对象（object）：附注标签对象中包含一个指向特定提交的引用。此处 object 中的值为我上面的提交对象的 SHA-1 值
  2. 标签指向对象类型（type）：指向的提交对象的类型
  3. 标签名称（tag）：附注标签对象包含一个唯一的标签名称，用于标识和引用该标签。
  4. 标签作者（tagger）：附注标签对象记录了标签的作者信息，包括姓名和电子邮件地址。作者是指创建该标签的人。
  5. 标签消息（Tag Message）：其中的 "secondTag"内容，附注标签对象包含一个可选的标签消息，用于描述标签的目的、里程碑或其他相关信息。标签消息可以提供其他开发者和团队成员了解标签的背景和用途。

我们再来看看 Tag 对象的存储方式

2. Tag 对象的存储方式

当执行带有 -a 或 -m <msg> 的 git tag命令时，Git 就会由如下操作：

  1. 创建对象：当你执行创建标签的操作（如git tag命令）时，Git会创建一个Tag对象。
  2. 内容提取：Tag对象包含标签的名称、类型、标签指向的提交、标签作者、标签创建时间、标签消息等信息。
  3. 哈希计算：Git会对Tag对象的内容进行SHA-1哈希计算，得到一个40个十六进制字符的哈希值。这个哈希值就是Tag对象的唯一标识符。
  4. 检查存储：Git会检查对象数据库中是否已存在具有相同哈希值的Tag对象。如果存在，则直接引用已有的对象；如果不存在，则进行存储。
  5. 存储对象：如果Tag对象是新的，Git会将它以哈希值为文件名存储在对象数据库中。对象数据库通常位于 .git/objects 目录下。存储时，Git将Tag对象的内容写入一个临时文件，并将该文件的路径与哈希值相关联。
  6. 压缩和索引：Git会对存储的Tag对象进行压缩，并将压缩后的数据写入真正的对象文件中。同时，Git会更新索引文件，将Tag对象的哈希值与文件路径进行映射。

三. Git 对象的存储

3.1 SHA-1 算法如何生成哈希值

SHA-1（Secure Hash Algorithm 1）是一种用于生成哈希值的加密算法。该算法将任意长度的输入经过散列运算转换为固定长度的输出。这个固定长度的输出就叫做对应输入内容的数字摘要或者哈希值。
那么对于 Git 对象中的 SHA-1 哈希值是如何生成的？
在 《Pro Git 2nd》这本书提到，SHA-1 哈希值是通过将待存储的数据+一个头部信息（header）一起做 SHA-1 校验运算而得到的。
而在头部信息由这些部分组成：

  • 对象类型字符串，比如"blob", “tree”, “commit”, “tag”
  • 空格
  • 数组内容的字节数
  • 空字节（null byte）

Git 会将上述的头部信息和文件原始数据拼接，来计算出 SHA-1 校验和。在 Linux 中有 sha1sum 命令可以生成 SHA1 哈希值，下面来验证一下我们生成的 SHA1 哈希值和 Git 是不是相同的：

//当前目录结构
│  a.txt
│
└─b
     c.txt

3.1.1. blob 对象的 SHA1 哈希值

先来看看 blob 对象，也就是 a.txt 对应的文件内容的 SHA1 哈希值生成过程，

//a.txt中的内容为：
$ cat a.txt
123
//字符数为3
$ git cat-file blob HEAD:a.txt | wc -c
3

其头部信息为 blob 3\000
在文件内容上加上头部信息，然后对新文件内容执行 SHA-1 哈希算法：

$ (printf "blob 3\000"; git cat-file blob HEAD:a.txt) | sha1sum
d800886d9c86731ae5c4a62b0b77c437015e00d2 *-

查看在 Git 仓库中是否找到该 SHA-1 值对应的 blob 对象

$ git cat-file -p d80088
123

说明执行 sha1 算法和 Git 操作算法得到的结果一致，验证了 Git 中 SHA-1 哈希值的生成过程

3.1.2. commit 对象的 SHA1 哈希值

此时在提交链最末端的 commit 对象内容是：

$ git cat-file commit master
tree 46bda27c4834d428a388841808fdaa7ca15a7bc1
parent 61b04b17412e1d9639db2a6b1b4e83319473a14a
author wangJW <1w@163.com> 1679818066 +0800
committer wangJW <1w@163.com> 1679818066 +0800

second commit

根据头部信息的组成，需要知道 commit 中的字符数：

$ git cat-file commit HEAD | wc -c
218

然后加上空格以及空字符串：commit 218\000，然后与 commit 对象内容拼接，将拼接后的内容计算 SHA1 校验和：

$ (printf "commit 218\000"; git cat-file commit HEAD) | sha1sum
2514fb61430ad5beea4f80e2548f1fbdfd97d74d *-

再来看看 HEAD 文件中对应的 Commit 对象以及其内容是不是与上面的 SHA1 相符：

$ cat .git/HEAD
2514fb61430ad5beea4f80e2548f1fbdfd97d74d
$ git cat-file -p 2514fb6
tree b79d07773ea2d47125f1e7078bbc8113a74a2fa7
parent 61b04b17412e1d9639db2a6b1b4e83319473a14a
author wangJW <1w@163.com> 1705493204 +0800
committer wangJW <1w@163.com> 1705493204 +0800

second commit

从结果可知，说明 Git 内部就是采用头部信息+内容利用 SHA1 算法得到的哈希值。
再来看看 tree 对象

3.1.3 tree 对象的 SHA1 哈希值

直接拿上面 commit 对象中的 tree 对象来做实验，首先查看 tree 对象中的内容和其中的字节数

$ git cat-file -p b79d0777
100644 blob d800886d9c86731ae5c4a62b0b77c437015e00d2    a.txt
040000 tree ceb3bfbba0a2f151a88628549113aa5c1be65bf5    b
//此时就是对应HEAD指针指向的树
$ git cat-file tree HEAD^{tree} | wc -c
61

然后根据头部信息+tree 对象内容信息计算 SHA-1 值：

$ (printf "tree 61\000"; git cat-file tree HEAD^{tree}) | sha1sum
b79d07773ea2d47125f1e7078bbc8113a74a2fa7 *-

发现此时计算出的 SHA-1 值和 commit 对象所指向的值完全相同，再次验证 SHA-1 生成方式。最后再来看看 tag 对象

3.1.4 tag 对象的 SHA1 哈希值

首先创建一个 tag 对象：

$ git tag -m "firstTag" firstTag
//创建成功
$ git tag
firstTag

获取这个 tag 对象的字节数，并执行 SHA1 哈希算法

$ git cat-file tag firstTag | wc -c
136

$ (printf "tag 136\000"; git cat-file tag firstTag) | sha1sum
d0c8f7e57f23b368152094bf3e57e70b3569cb13 *-

从 tag 对象的执行结果说明，SHA1 哈希值生成方式正确。

3.2 Git 对象的存储位置

从前面查看 blob 对象内容时提到过，在 Git 中的对象存储在 Git 仓库的 .git/objects 目录下。
在下列情况中，会触发 Git 存储对象的操作：

  1. git add：在执行 git add 命令暂存某个文件 时，Git 将会将文件的内容转换为一个 Blob 对象，并将该对象存储在本地对象数据库中。这个操作将文件添加到暂存区（Staging Area），为接下来的提交做准备。
  2. git commit：执行 git commit 命令时，Git 首先会创建一个新的 Commit 对象。这个 Commit 对象包含了提交的元数据信息，如作者、提交时间、提交信息等。同时，Git 会创建一个对应的根目录的 Tree 对象，记录了当前提交时仓库中所有文件的快照。最后，Git 将这个 Commit 对象存储在本地对象数据库中，并将当前分支指向该 Commit 对象，表示当前的工作状态。
  3. git tag：执行创建附注标注命令时，Git 会创建一个 Tag 对象，该对象包含标签的元数据信息，并指向一个特定的 Commit 对象。这个 Tag 对象会被存储在本地对象数据库中，以便后续引用。
  4. git merge：执行 git merge 命令时，Git 会创建一个新的 Commit 对象，该对象包含合并的元数据信息，并引用两个或多个合并的分支的 Commit 对象。Git 会将这个新的 Commit 对象存储在本地对象数据库中，并将当前分支指向该新的 Commit 对象。

四、 总结

本文通过 .git 目录角度解析 Git对象

  1. Git 对象主要有以下四种类型：Blob存储文件内容,Tree记录文件结构,Commit记录历史,Tag添加标签。
  2. Git 通过提取对象内容加头信息，使用 SHA-1 算法生成哈希值作为唯一 ID
  3. Git 对象存储于 .git/objects目录下，其中对象 ID 值前两位作为目录名，后 38 位作为文件名
  4. 在在执行暂存（add）、提交（commit）、合并（merge）、打标签（tag）等操作时都会触发 Git 对象的存储

参考资料

《Git 权威指南》

《Git Pro》文章来源地址https://www.toymoban.com/news/detail-809577.html

到了这里，关于深入剖析 Git 对象底层原理的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • Linux源码解读系列是一套深入剖析Linux内核源码的教程，旨在帮助读者理解Linux操作系统的底层原理和工作机制

    Linux源码解读系列是一套深入剖析Linux内核源码的教程，旨在帮助读者理解Linux操作系统的底层原理和工作机制

    Linux源码解读系列是一套深入剖析Linux内核源码的教程，旨在帮助读者理解Linux操作系统的底层原理和工作机制。该系列教程从Linux内核的各个模块入手，逐一分析其源码实现，并结合实际应用场景进行讲解。通过学习本系列，读者可以深入了解Linux操作系统的底层机制，掌握

    2024年01月21日
    浏览(47)
  • 三分钟上手！一文看懂 Git 的底层工作原理

    三分钟上手！一文看懂 Git 的底层工作原理

    这是一篇能让你迅速了解 Git 工作原理的文章，实战案例解析，相信我，3 分钟，绝对能够有收获！   Git 的本质是一个文件系统（很重要，记住这句话，理解这句话），工作目录中的所有文件的历史版本以及提交记录（commit）都是以文件对象的方式保存在 .git 目录中的。 我

    2024年02月12日
    浏览(44)

  • Git如何查看分支列表？具体步骤是怎样的？底层原理是什么？

    要查看 Git 中的分支列表，可以使用 git branch 命令。该命令会列出当前仓库中所有的本地分支，并在当前分支前面加上一个星号（*）以标识当前所在的分支。 具体步骤如下： 打开终端或命令行窗口，进入 Git 仓库所在的目录。 运行 git branch 命令，该命令会列出所有本地分支

    2024年02月11日
    浏览(43)
  • ptmalloc底层原理剖析

    ptmalloc底层原理剖析

    目录 一、概述 二、基础了解 2.1 32位进程默认内存布局 2.2 brk  sbrk  mmap 三、内存管理 2.1 结构 2.1.1 main_area 与 non_main_area 2.1.2 malloc_chunk 2.1.3 空闲链表bins 2.1.4 初始化 2.2 内存分配与释放 2.3 使用注意 三、ptmalloc、tcmalloc与jemalloc实现机制对比分析 ptmalloc是开源 GNU C Library (gli

    2024年02月16日
    浏览(37)
  • GIT保存记录原理之commit对象

    GIT保存记录原理之commit对象

    GIT 中提交对象非常的重要，我们通过它记录代码提交过程、进行文件保存、回退等操作，那么它是怎样帮助我们记录这些信息的呢？其实就是都保存在项目根目录的 .git 文件夹中。 新建空项目 gitDemo 使用 git init 初始化，在文件夹根目录下会生成 .git 文件夹，文件夹中会生成

    2024年02月10日
    浏览(27)
  • git文件管理与索引，深入理解工作原理，java面试手册升级版

    git文件管理与索引，深入理解工作原理，java面试手册升级版

    git add 命令的意义是将暂存一个文件。以Git文件分类而言，如果一个文件是未追踪的，那么 git add 会将文件的状态转化为 已追踪状态 。如果git add 作用一个目录 ，那么该目录下的 所有文件都会被递归为已追踪状态暂存起来 。接着之前的例子，继续进行讲解。 $ git status On b

    2024年04月12日
    浏览(45)
  • 深入理解 Flutter 图片加载原理 | 京东云技术团队

    深入理解 Flutter 图片加载原理 | 京东云技术团队

    随着Flutter稳定版本逐步迭代更新，京东APP内部的Flutter业务也日益增多，Flutter开发为我们提供了高效的开发环境、优秀的跨平台适配、丰富的功能组件及动画、接近原生的交互体验，但随之也带来了一些OOM问题，通过线上监控信息和Observatory工具结合分析我们发现问题的原因

    2024年02月12日
    浏览(35)
  • 2.【Linux】（进程的状态||深入理解fork||底层剖析||task_struct||进程优先级||并行和并发||详解环境变量）

    2.【Linux】（进程的状态||深入理解fork||底层剖析||task_struct||进程优先级||并行和并发||详解环境变量）

    Linux把所有进程通过双向链表的方式连接起来组成任务队列，操作系统和cpu通过选择一个task_struct执行其代码来调度进程。 1.运行态：pcb结构体在运行或在运行队列中排队。 2.阻塞态：等待非cpu资源就绪（硬盘，网卡等资源） 3.挂起态：一个进程对应的代码和数据被操作系统因

    2024年01月22日
    浏览(43)
  • Redis底层原理深入学习

    Redis底层原理深入学习

    一、基本类型及底层实现  1.String 1） 使用场景： 简单字符串存储、分布式锁、计数器、全局唯一ID 2） 数据结构： C语言中String用char[]表示，源码中用SDS封装char[]，这是Redis存储的最小单元，一个SDS最大可以存储512M信息。  Redis对SDS再次封装成RedisObject，核心作用有两个： ①

    2024年02月08日
    浏览(42)

  • SpringBoot 原理深入及源码剖析

    SpringBoot 依赖管理 SpringBoot 项目间接继承 spring-boot-dependencies，该文件对常用技术框架进行了统一版本管理，所以在SpringBoot 项目 pom.xml 引入spring-boot-dependencies管理的依赖文件不需要标注依赖文件版本号。引入 starter 就可以实现对应场景开发，而不需要额外导入相关依赖文件。

    2024年02月02日
    浏览(77)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包