Git究竟是如何工作的?

深入探究 Git 的内部机制, 学习并精通 Git

简介

Git无疑是现代软件开发的主要基石之一 . 它是协调开发人员工作的必备工具箱, 多年来已成为开源运动的基本引擎. 一个简单的例子是, 截至2021年11月, 根据Git的主要仓库管理器GitHub报告可知, 已有超过7300万名开发人员和2亿多个仓库.

一些程序员每天都要与Git打交道, 并普遍应用其中的关键概念. 在本讲座中, 我们将通过深入Git内部, 探索Git的基本基础, 继续向前迈步. 什么是分支? 什么是分支头? 合并分支意味着什么? 今天, 我们将回答这些问题以及其他问题.

打地基

Blob, 树和提交 是Git数据结构的主要组成部分. 就像房子由砖块砌成, 图由边和节点组成一样, 这些元素构成了Git的地基.

要理解这一切, 让我们从一个例子开始. 假设我们创建了一个空仓库. 当我们启动git init命令时, git会自动创建一个名为.git的隐藏文件夹, 用来存储内部信息.

Blob

现在, 假设我们创建了一个名为myfile.txt的文件, 并使用git add myfile.txt.命令将其添加到我们的版本库中.

当我们执行这个操作时, Git会创建一个blob , 这是个文件, 位于.git/objects子文件夹中, 存储了 myfile.txt的内容, 但**不包括任何相关元数据(如创建时间戳、作者等). 因此, 创建 blob 就像存储图片文件的内容一样.

Blob 的名称与其内容的哈希值**相关. 内容散列后, 前两个字符用于在*.git/objects*中创建子文件夹, 散列的其余字符则构成 blob 的名称.

总之, 向 Git 添加文件的步骤如下:

1. Git 获取文件内容并对其散列
2. Git 在.git/objects文件夹下创建一个 blob. 哈希值的前两个字符用于在该路径下创建一个子文件夹. Git 会在其中创建一个blob, 其名称由哈希值的其余字符组成.
3. Git 会将原始文件(压缩版)的内容保存在blob中.

Git 创建blob的过程描述

请注意, 如果我们有一个名为myfile.txt的文件和另一个名为ourfile.txt的文件, 而这两个文件**共享相同的内容, 它们的哈希值也相同, **因此它们被存储在同一个blob中.

如果我们对myfile.txt稍作修改, 并将其重新添加到版本库中, Git 也会执行同样的过程.

树

假设我们在版本库中创建了一个名为subfolder的子文件夹, 也让我们在这个子文件夹中创建一个名为yourfile.txt的文件, 并将其添加到版本库中. 在此过程中, Git 会根据我们在上一段中定义的流程为yourfile.txt创建一个新的 blob.

Git会对第二个名为yourfile.txt的文件进行散列, 该文件保存在.git/objects文件夹中

此时, 我们使用git commit命令提交myfile.txt和yourfile.txt:

• 创建仓库的根树
• 创建提交

让我们集中讨论第一步. 那么, 什么是根树呢? 根树存储了整个版本库的文件和文件夹结构 . 它是一个文件, 包含对版本库中每个 blob 或子文件夹的引用, 以递归方式建立.

根树的每一行都引用一个 blob 或其他子树, 这些子树又以同样的方式引用其他 blob 或其他子树 . 因此, 树相当于目录 : 就像我们可以从目录访问文件和子文件夹一样 , 我们也可以从树访问 blob 和子树.

根树和与mysubfolder相关的子树的内容

一旦 Git 创建了根树和所有相关的子树, 它就会执行上文所述的散列和存储操作. 更准确地说, 它会对每棵树进行散列 , 并使用前两个字符在.git/objects中创建一个子文件夹, 而其余的散列字符则构成保存文件的名称. 因此, 在这个过程中, 我们得到的新文件数量与数据结构中树的数量相同.

Git 会对根树和与mysubfolder相关的子树进行散列, 两者都存储在.git/objects文件夹中

提交

运行git commit命令后, 第二步是创建提交. 提交内容存储在一个文件中, 其中包含与根树, 父提交(如果有)相关的信息, 以及一些元数据, 如提交者的姓名, 电子邮件地址和提交信息.

提交文件包含对根树的哈希值, 作者和提交者, 提交时间戳(本例中为 163267988), 父提交(本例中为空, 因为这是第一次提交)和提交消息的引用.

提交文件创建后, Git 会对其内容进行散列, 并使用散列名将内容存储到一个新文件中, 与上述操作完全相同(前两个字符构成.git/objects中的子文件夹名称, 而散列名的剩余部分构成实际名称).

到目前为止所有树, 提交和 Blob 的结构

就是这样! 恭喜你, 你刚刚了解了 Git 的结构. 现在, 有了这些概念, 要定义分支, 标记, 头部和合并等概念就非常简单了!

垒砖墙

分支

分支是对提交的命名引用 . 例如, 当创建一个名为mybranch的新分支时(使用git checkout -b mybranch命令), Git 会在.git/refs/heads路径下生成一个名为mybranch的新文件, 该文件的内容是创建分支的提交的哈希值.

最初, master 和mybranch都指向同一个提交

然后, 当我们在mybranch上提交时, Git 会执行之前定义的操作(创建根树和提交文件), 然后用新的提交哈希值更新分支的文件.

执行新提交后, mybranch文件的内容将被更新. 现在, mybranch文件指向新的提交

因此, 分支是文件, 用于跟踪提交, 我们每次提交都会更新这些文件的内容.

标签

标签是对特定提交的永久引用 . 例如, 当我们创建一个名为mytag的新标签时(使用git tag mytag命令), Git会在.git/refs/tags路径下生成一个名为mytag的新文件.

不过, 当我们继续工作并在同一(或其他)分支上提交时, 标签文件不会更新, 而是继续指向其创建时的特定提交 . 与分支文件不同, 标签在执行新提交时不会移动.

执行了新提交, 但文件mytag并未更新

HEAD

HEAD 在 Git 中执行一些任务:

• 因此, 当我们执行git branch时, Git 会通过HEAD来了解我们所在的分支.
• 它引用下一次提交的父提交, 因此HEAD指向的提交将是下一次提交的父提交. 回想一下, 当我们执行提交时, 的父提交会保存在提交文件中.

如果我们在分支 master 上, HEAD就会引用该分支. 如果我们打开HEAD文件, 就会看到"ref: refs/heads/master". 相反, 如果我们切换到mybranch分支, 并打开.git文件夹中的HEAD文件, 我们会看到"ref: refs/heads/mybranch". 因此, HEAD并不直接指向某个提交, 而是指向某个分支, 而该分支又指向该分支上的最新提交. 通过这种方式, Git 可以追踪当前已签出的提交.

我们在分支mybranch上. HEAD指向文件mybranch, 而文件mybranch又指向一个特定的提交. 与分支 master 相关的文件master指向另一个提交

当我们在分支上执行提交时, Git 会读取HEAD文件的内容, 并写入被引用为父提交的提交 . 从这个意义上说, HEAD(间接)提供了下一次提交的父提交.

提交文件的内容. HEAD(间接)提供了父提交

现在, 在 Git 中, 我们可以签出到前一个提交, 然后从那里开始修改. 这种模式被称为分离模式. 在这种情况下, HEAD直接指向一个提交, 而不是分支 . 请注意, 这样做可能会有危险, 因为我们有可能丢失新的提交. 事实上, 在执行一次提交后, 如果我们签出到一个分支, 我们就无法再返回到这个新提交, 因为它没有被任何分支引用 ! 这就是为什么我们在分离模式下提交任何改动之前, 总是要创建一个新分支的原因!

Merge

Merge允许连接两个或多个提交. Merge有两种类型:

• 第一种是当两个分支发生分歧时. Git 会创建一个有两个父分支的新子分支 . 第一个父分支是我们所在的分支, 第二个父分支是将要Merge的分支. 提交文件将有两个父节点, HEAD被移动到新的子节点上.
• 第二种情况是, 两个分支没有分叉, 但其中一个分支是另一个分支的延续. 在这种情况下, 合并被称为快进合并(fast-forward merge), 它不是真正意义上的合并, 因为没有冲突 . 在这种情况下, Git 只是把HEAD和当前分支移到要合并分支的同一个提交点上.

就到这了. 恭喜你看到了这里! 希望你喜欢这篇文章! 现在, 你应该对 Git 的工作原理有所了解了. 如有任何疑问, 欢迎随时发表评论!

后会有期了, 要持续发光哦! :)