git - 每个 git commit 的树对象内容存储了什么信息

Question

每个 Git 提交对象都指向一个树对象。 是否每个提交树对象都存储了它的所有条目，还是只添加新条目并且只包含来自提交父项的增量？

例如Linux 源代码有 1M 次提交和数千个对象(master 有 70,000 个)。如果每个提交对象都包含所有对象的条目，从长远来看会占用大量空间。此外，即使提交/推送了一行更改，也需要进行大量处理和传输。

我理解 Git 的理念是存储文件的快照而不是增量，但在那种情况下，只会存储更改的文件。

在下面的示例中，70951b429e0e1191a8c1d9e34248cd76453ef544 包含(或显示为包含)所有 5 个文件，即使只添加了一个文件也是如此。

[test]$ls
a.txt  b.txt  c.txt  d.txt
[test]$echo r5 > e.txt
[test]$git add -A && git commit -m "r5"
[master 51f6941] r5
[test]$git cat-file -p 51f6941
tree 70951b429e0e1191a8c1d9e34248cd76453ef544
[test]$git cat-file -p 70951b429e0e1191a8c1d9e34248cd76453ef544
100644 blob 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5    a.txt
100644 blob 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5    b.txt
100644 blob b6693b64f528de38cde5533acd781fde743bc3df    c.txt
100644 blob 91174caefafdc81d34e302874c86c6e4d5212075    d.txt
100644 blob 29f4cfc46ba3a0bde55bce8f44ac3590e2108da4    e.txt

Answer 1

从逻辑上讲，每次提交都包含每个文件(好吧，提交中的每个文件)的完整快照。

如果您选择一个提交，例如，通过其哈希 ID，并在该提交上运行 git checkout，您的工作树将由该提交中的文件填充。也就是说，您的工作树采用该快照。从该提交切换到其他提交，例如，少了三个文件，Git 会删除这三个文件(并根据需要更新其余文件)。

If every commit object contains all the objects' entries, it would take huge space in the long run.

除了……它没有。这涉及两个惊人的(或不是真的那么惊人的)聪明壮举。

第一个出现在这里:

[test]$git cat-file -p 70951b429e0e1191a8c1d9e34248cd76453ef544
100644 blob 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5    a.txt
100644 blob 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5    b.txt
100644 blob b6693b64f528de38cde5533acd781fde743bc3df    c.txt
100644 blob 91174caefafdc81d34e302874c86c6e4d5212075    d.txt
100644 blob 29f4cfc46ba3a0bde55bce8f44ac3590e2108da4    e.txt

请注意，blob 哈希 ID 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5 出现了两次:一次用于 a.txt，一次用于 b.txt。

a.txt 和b.txt 的内容只有一份。由此我们可以得出结论，在a.txt和b.txt中的内容都是一样。

因此，如果您提交 100 个文件，然后进行新提交，其中 99 个文件与之前提交的 99 个文件相同，您只是重新使用 99 个 blob 对象。它们不必再次存储。

Git 以这种方式自动删除重复的文件内容。

第二点聪明发生在以后。最初，所有对象都存储为 zlib 压缩文件(.git/objects/ 中的文件，尽管您不应该指望这一点)。如果您更改文件中的几个字节并使用 git add 并且新的 blob 对象不是某个已经存在的 blob 对象的 100% 精确匹配，您将获得这些对象中的一个新对象。这些在内部称为松散对象。

当周围有足够多的松散对象时，或者如果需要，Git 会将松散对象打包到一个打包文件中。此时，通常可以对可获利的增量压缩对象进行压缩。这种压缩是真正聪明的代码。

当您使用 git fetch 或 git push 时，Git 会找出哪些对象需要通过网络传输并构建一个所谓的瘦包。这是您看到 counting 和 compressing objects 消息的地方。 Git 然后通过网络发送精简包；另一端的 Git 修复了薄包，使其成为常规(胖)包。当打包文件过多时，Git 将重新打包 打包文件，将您从许多 *.pack 和 *.idx 文件中压缩到又是几个(或一个)。

(这里偶尔会出现一些错误。最近修复了处理大量打包文件的问题。有几个较旧的错误，其中遗留了太多松散的对象。偶尔手动 git gc 有时有助于解决这些错误，但过于频繁地使用 git gc 可能会适得其反。)