commit是作为文件实现的吗？

Question

在关系数据库系统中，表通常被实现为文件，或者很少情况下数据库被实现为文件。

Git可以看作是一个数据库系统。在Git中，什么是作为文件实现的: blob、树、提交、存储库？

Answer 1

Git存储库是一个文件集合，其中的“对象”是包文件(压缩的)或松散的(未压缩的文件)。

参见"Git repository layout"：

如Git Basics中所述

你会看到这些散列值在

中随处可见，因为它用得太多了。事实上，Git在其数据库中存储的所有内容不是通过文件名，而是通过其内容的哈希值。

Git目录是Git存储项目元数据和对象数据库的位置。这是Git最重要的部分，也是您从另一台计算机克隆存储库时所复制的内容。

工作树是项目的一个版本的单个签出。这些文件将从Git目录中的压缩数据库中取出，并放在磁盘上供您使用或修改。

注意: Git本身的第一次提交(commit e83c516)提到：

有两个对象抽象：“对象数据库”和“当前目录缓存”。

从字面上看，对象数据库只是一个内容可寻址的对象集合。

所有对象都按其内容命名，该内容由对象本身的SHA1散列近似表示。

对象可以引用其他对象(通过引用它们的SHA1散列)，因此您可以构建对象的层次结构。

在内容寻址集合数据库中有几种类型的对象。它们都是用zlib压缩的，并以其类型的标记和有关数据的大小信息开始。

SHA1散列始终是压缩对象的散列，而不是原始对象。

Answer 2

Git可以看作是一个数据库系统...

这实际上是一个合理的高级视图。然而，在使用这种方法时，Git至少有两个键值存储(以及一些可选的附加存储，我们在这里将忽略它们)。一种是名字-- Git称之为引用，它有专门的形式，比如分支和标记名--并将它们转换成散列ID值。另一个数据库获取散列ID键并将其转换为对象。

从字面上看，提交是一个“提交”类型的对象。每次提交都会引用一个"tree“类型的(单个)对象，该对象表示保存的快照。该树依次引用附加的子树和/或表示文件内容的"blob“对象，或者对于符号链接，引用该链接的目标。

在

中，实现为文件的是什么: blob、树、提交……

这里的答案既是肯定的，也是否定的。作为VonC said，这些都只是对象。有四种类型，这是我们到目前为止命名的三种类型，加上“带注释的标签”。每个对象要么存储为松散对象(在这种情况下，它位于.git/objects/目录下的文件中)，要么存储为压缩对象。包文件存储在.git/objects/pack/中(至少是成对的文件:一个“包索引”，以及对应于该索引的内容)。一个包文件存储许多对象，使用增量编码，以便可以通过部分提取其他对象的部分来提取对象。

(包文件的格式很复杂，已经有了几次修订。)

松散对象的文件名是它的散列ID键，用十六进制表示，前两个字母用/分隔符从其余的38个字母中分离出来，因此给定散列ID 1234567...，该对象存储在.git/objects/12/34567...中。

在相对较少的情况下，您可以将同一对象存储为松散对象，并将其存储在一个或多个包文件中。但是，由于对象的名称是其内容的散列，因此所有副本都应该匹配。当Git解压缩一个对象时，它会在运行过程中重新计算散列，并且当且仅当产生的散列与Git最初查找对象时所使用的键匹配时，才会声明数据有效。否则，内容已被损坏，可能是由于存储介质故障。

(如果任何一个副本被损坏，您可以尝试所有其他副本，但通常情况下，只使用单独的克隆会更容易。Git还将验证每个克隆操作的哈希完整性。Git没有提供花哨的修复工具来尝试定位第二个副本，但它确实有工具来分解单独的包文件，所以你可以手动完成。)