每个 git commit 的树对象内容存储哪些信息

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

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

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

在下面的示例中，70951b429e0e1191a8c1d9e34248cd76453ef544 包含（或显示为 containsig）所有 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

无论如何，每个提交都保存（从逻辑上讲）每个文件（好吧，提交中的每个文件）的完整快照。

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

如果每个提交对象都包含所有对象的条目，从长远来看将占用巨大的空间。

但……事实并非如此。其中涉及到两项令人惊奇（或者不是那么令人惊奇）的聪明才智。

第一个出现在这里：

[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 哈希 ID9a6c8d12dea8859b821b2ba705f7efd6cc914aa5出现两次：一次为a.txt一次b.txt.

只有one copy两者的内容a.txt and b.txt。由此我们可以得出结论，无论是in a.txt, and in b.txt，内容相同。

因此，如果您提交 100 个文件，然后进行一次新提交，其中 99 个文件与前一个提交的 99 个文件相同，您只需re-used99 个斑点对象。它们不必再次存储。

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

第二个小聪明发生了later。最初，所有对象都存储为 zlib 压缩文件（位于.git/objects/，尽管你不应该指望这一点）。如果您更改文件中的几个字节并使用git add并且新的 blob 对象与某些已存在的 blob 对象并非 100% 完全匹配，您将获得这些对象中的一个新对象。这些被称为loose对象，内部。

当周围有足够多的松散对象时，或者如果需要的话，Git 会更早packs将松散的物体放入打包文件。此时，可以有利地进行增量压缩的对象通常都是这样。这种压缩是真正聪明的代码。

当你使用git fetch or git push，Git会找出哪些对象需要通过网络传输并构建一个所谓的薄包装。这是你看到的地方counting and compressing objects消息。然后 Git 通过网络发送精简包；另一端的 Git 修复瘦包，使其成为常规（胖）包。当包文件太多时，Git 会repack包文件，带你从许多*.pack and *.idx文件再次减少到只有几个（或一个）。

（这里偶尔会出现一些错误。最近有一个修复程序可以处理大量包文件。有几个较旧的错误，其中留下了太多松散的对象。偶尔的手册git gc有时有助于解决这些错误，但使用git gc太频繁可能会适得其反。）