【Git教程】（四）版本库 —，2024-2024历年华为跳动大数据开发面试真题解析

Git 主要由两个层面构成。其顶层结构就是我们所用的命令，例如 log 、reset 或 commit 等。这些命令使用起来很方便，并提供了许多可调用的选项。Git 的开发者们称它们令为瓷质命令 (porcelain command)。
而对于其底层结构，我们则称之为管道 (plumbing) 。 这里主要是一组带有少量选项的简 单命令，瓷质命令就是以此为基础被构建出来的。管道命令很少被直接用到。本章将为你提供一些了解该系统管道层结构的机会。

1️⃣ 一种简单而高效的存储系统

Git 的核心是一个对象数据库。该数据库可用来存储文本或二进制数据，例如对于某文件 的内容。我们可通过带 -w 选项 (w 代表写入)的 hash-object 命令将其作为一条记录插入到该对象数据库中。

> git hash-object -w hello.txt
28cf67640e502fe8e879a863bdlbbcd4366689e8

每当我们存储了这样一个对象， Git 就会返回一个40个字符的代码，这是被存储对象的 键值。请记住它，我们日后需要用该键值配合带 -p 选项 (p代表打印)的cat-file 命令来访问这个对象。

> git cat-file -p 28cf67640e
Hello World!

对象数据库是一个非常高效的实现。即使对于一个有着非常长提交历史的大型项目(例如Linux内核，这是一个拥有 200000次提交和近两百万个对象的项目)来说，访问其版本库 中对象的操作也几乎可在瞬间完成。Git 非常适合用于那些拥有大量小型源文件的项目。其性能瓶颈只有在总数据量非常巨大的时候才能显现出来。对于那些想要管理大量二进制文件的人来说，Git 版本库显然是不二的选择。

2️⃣ 存储目录：Blob 与 Tree

在文件和目录的存储上，Git 使用了一种包含两种节点类型的简单树结构。其文件内容将 保持不变，并以blob 对象的形式按字节被存储对象数据库中。而目录则将用tree 对象来表示， 它们看起来应该像如图所示。

> git cat-file -p 2790ef78
100644 blob 507d3a30ae9ed53bcf953744c5f5c9391a263356 README
040000 tree 91c7822ab43800b0e3c13049519587df4fd74591 src

正如你将如上看到的， tree 对象中包含了文件和子目录。其中的每个条目都被分配了 相应的访问权限(例如上面的100644)、类型(即 blob 还是 tree), 以及由该文件内容、该文
件或目录名称生成的散列值。

3️⃣ 相同数据只存储一次

为了节省内存空间， Git 对于相同数据将只存储 一 次。例如在下面这个例子中，foo.txt 和 copy-of-foo.txt 将返回相同的散列值，因为它们的文件内容是相同的。

> git hash-object -w foo.txt
a42a0aba404c21le8fdf33d4edde67bb474368a7
> git hash-object -w copy-of-foo.txt
a42a0aba404c21le8fdf33d4edde67bb474368a7

通过这种方法， Git 不仅能够节省内存，同时也能在性能上得到提升。许多Git 操作之所以快，就是因为它们的算法只比较相关的散列值，而不需要查看其实际数据。

4️⃣ 压缩相似内容

Git 不仅可以对相同的文件内容进行合并，每当程序员们所创建的新文件在内容上与前人 只有区区几行的区别时，Git 可以采用增量方法来存储这些文件，在这种情况下，包文件中将只存储原始版本后来被改变的那一部分。

要想做到这一点，我们就要在想节省空间时使用 gc 命令。这样一来，Git 就会删除所有多余的、不再接受任何分支头访问的提交，并将剩下的提交存储到包文件中。对于那些源代码占绝大多数的项目来说，这就等于实现了某种令人惊叹的高压缩处理。通常情况下，当前版本未压缩的工作区内容大小往往要比包含多年项目历史并打包的Git 版本库还要大得多。

5️⃣ 不同文件的散列值相同

当不同文件的散列值相同时，情况会很糟糕，因为 Git 是通过散列值来识别内容的。因此， 一 旦内容各不相同的文件出现散列值相同的情况，Git 就无法提供正确的数据了，我们称这种情况为敬列冲突(hash collision)。

好消息是，敬列冲突是一种非常罕见的事件。其原因在于，散列值的可能取值至少有2160 种。而即使是Linux 内核项目在运作5年之后，版本库中也就“仅有”大约221个对象。

当然从理论上而言，SHA1 敬列算法是有缺陷的，你可以在 SHA1 算法中找到251 中会 引起敬列冲突的操作。然而，格拉茨科技大学 (Graz University of Technology) 的一个研究项目曾从2007年尝试到2009年，目的是想找出一个(!) 这样的散列冲突，结果以失败告终。

总而言之，在当今版本控制所在的环境下，我们可以认为它是安全的。

6️⃣ 提交对象

我们所做的历次提交也被存储在对象数据库中，它们的格式很简单。

> git cat-file -p 64b98df0
tree 319c67d41a0b3f7464550b41db4bb1584939ad2a
parent 6c7f1ba0828a5b595026e08d2476808105a6b815
author Bjorn Stachmann <bs@test123.de>1295906997  +0100
committer Bjorn Stachmann <bs@test123.de>1295906997  +0100
Section on trees & blobs.

除了作者、提交者、日期以及注释这些元数据外，每个提交对象还在对象数据库中放入 了一些其他对象的散列值。例如： tree 对象负责描述该提交的内容。它还包含了该项目的根目录信息，并且与上文提到的一样，它也将以tree 和 blob 对象的方式呈现。而 parent 对象则指的是它的上一次提交。

7️⃣ 提交历史中的对象重用

除了最初的那次提交外，版本库中的每个提交对象上面都至少会存在一个前提交对象(即 父对象)。通常来说， 一次提交往往只涉及项目中少数文件的修改，其他大部分文件和目录不会发生变化。所以，我们会希望 Git 尽可能多地重用前次提交中的相关对象。

下面我们来看一个具体的例子(见下图)。某一提交(即自顶向下第二排中第二个被 实线箭头所指向的那个标题为 “commit” 的方框)中包含了一个README 文件，以及一个 用于包含其他文件的 src 目录。然后，如果在新建的提交(即图中第一行用虚线箭头所指向 的那个标题为 “commit” 的方框)中，被修改的只有 README 文件， Git 就会专门为该 README 文件创建一个新的blob对象。而对于src 目录，则继续沿用现有的tree对象与相应的 blob 对象。

8️⃣ 重命名、移动与复制

在许多版本控制系统中，我们都可以对文件的重命名及其修改时间的历史进行跟踪监视。
它们大多数通常是通过某个特定的文件移动或重命名命令来实现的。例如在 Subversion 中，我们可以用 svn move 来移动文件。但是如果用户想要将文件在图形界面中拖放到某一新的位置的话， Subversion 就无能为力了。对于这种情况， Subversion 不会认为这是个移动操作，而会将其记录为先删除，再另行新建该文件的操作过程。

对此，Git 采用了不同的方法：它没有选择去存储与文件移动操作相关的信息，而是采用 了重命名检测算法。在该算法中，如果一个文件在某一次提交中消失了，它依然会存在于其 前次提交中。而如果某个拥有相同名字或相似内容的文件出现在了另一个位置， Git 就会自动检测到。如果是这种情况， Git 就会假定该文件被移动过了。下面我们以下图中的情况为例 来演示一下。你可以看到：第二次提交中已经没有了 foo.txt 文件，它可能被移动了。随后，Git 又自动检测到新增文件中有一个与之内容相似的文件，位于src/foo-moved.txt, 这一过程就成为了重命名操作。

Git 会自行显示出被重命名或移动的文件。

1. 先获取一份摘要
   我们可以用 log 命令的-M 选项 ( 即“move”) 来激活重命名的检测算法。如果想要格式化输出的信息，我们可以对其使用–summary 选项来显示文件修改的相关信息。但这段输 出很长也是个问题。如果我们想要简短一些，也可以用grep命令来对输出进行筛选。另外，百分比显示了源文件和目标文件的相似度。

> git log --summary -M90% | grep -e "^ rename"
rename foo.txt => foo-renamed.txt(90%)
rename src/{before =>after}/bar.txt(100%)

2. 跟踪被移动文件的历史
   我们可以用 log 命令的–follow 选项来连续取出文件被重命名之后的历史记录(当然，该做法仅适用于单文件操作)。如果不使用该选项，日志就会在该文件被重命名的那一刻停止。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数大数据工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上大数据开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注大数据获取）

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

果你觉得这些内容对你有帮助，可以添加VX：vip204888 （备注大数据获取）**
[外链图片转存中…(img-2edQZe5C-1712996668731)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！