大型项目的git历史数据

Question

我是一个Git的新手，并试图理解这些原则。正如我在Git中所了解的，每个文件都按照Git Book以及this post完全存储。然而，git book还指出了git gc，它压缩二进制文件并计算文本文件的差异，这种说法似乎与git存储完整文件的第一点相矛盾。

1）有人可以解释哪一个是正确的？如果git gc确实计算了部分差异，并且它恰好在很长一段时间后运行，这是否会确保所有差异都是从基本版本创建到所有分支？如果git gc没有定期运行，这是否意味着很多计算时间？

2）考虑到像Android这样的项目有大量的源文件和资源文件，这似乎表明git会在每次提交时大小都会增大。当开发者提取Android源代码时，如果它为所有源文件和二进制文件提取整个历史记录，是否会占用大量空间？我在这里错过了什么吗？这是如何长期持续的？

Answer 1

Git是一个花哨的内容寻址文件系统。 理论上，它存储每个修订中每个文件的完整内容，并且每个blob（文件内容）都有一个可以被检索的文件。在这种情况下，git实际上有能力将文件存储为类似文件的diff（通常是以前的版本，但不一定必须），但是这完全发生在git存储文件的最低级别。 git用户不仅不必考虑它，即使大部分git 工具都不必考虑它。

至于大小的问题，因为有在“混帐filesstem”各种形式的压缩，因为他们是很有效的，包含项目的整个历史上.git目录通常是小于代码的单一结帐，直到项目达到数十万次提交。

如果一个存储库变得难以管理的庞大，有可能（借助像git graft这样的工具）将项目的历史拆分成不同的存储库，沿着新/古历史或活动/存档分支或其他东西像那样。

Answer 2

git gc用于清理/压缩存储库中的松散对象。它通过打包对象（文件/树/提交的每个完整状态）来完成此操作。 diff可以从以前的文件创建，也可以来自完全不相关的文件，但具有类似的内容git。

为了解决问题2，如前所述，git的确收拾对象。尽管从概念上讲，每个文件都有一个完整的副本，但是在运行gc时，它们会被打包。至于存储二进制文件，version control in general is not the best first choice.

Answer 3

方式git gc计算存储的差异并不一定与文件的历史有关。事实上，我记得在某个地方读书，但目前找不到参考资料，可能会选择更多最近“基地”修订版，因为这些是您最有可能签出的版本。如果您有10,000个修订版并正在检出最新版本，则不需要将10,000个差异版应用于修订版1以获取所需的版本。

某些操作会自动运行git gc。 pull就是其中之一，所以在运行它之间不太可能会很长时间。没有什么能够阻止你在每次提交之后运行它，如果你这么倾向。本质上，这是其他版本控制系统在幕后执行的，也是git如此之快的主要原因之一。