本地 repo 和 bitbucket 的大小差异

Question

我有一个本地仓库。我.git用du -csh <foldername>命令检查了文件夹的大小。它是 168 MB。我把它推送到我的 bitbucket 仓库。我检查了下载的存储库大小仅为 134 mb。

这怎么可能？

Answer 1

首先，让我们解决整个存储库的大小。（跳到第二个标题部分跳过这部分。）

通常，“纯服务器”存储库是 Git 所谓的裸存储库，即没有工作树的存储库。

请记住，在任何Git仓库，¹你有：

• 曾经做过的每一次提交，都以 Git-only 形式存储，加上
• 与这些提交相关的每个文件，也以 Git-only 形式存储，加上
• 一些杂项开销数据（标签、树、引用名称、“信息”、钩子等）。

这^两个都没有“您在计算机上正常使用的文件”的形式，所以如果您打算用提交做任何事情，除了将它发送到另一个 Git，您可能需要一个工作树。该--bare服务器上的存储库大多只是提交转移到其他控释片（接收和发送），所以它的空间的浪费，实际上适得其反，要保持当前的工作副本提交。

由于服务器省略了工作副本，您通常应该期望服务器端裸存储库比客户端非裸存储库小。因此，您观察到的结果应该完全不足为奇。什么是令人惊讶的是，有时，服务器的大小仓库是更大的。这有很多可能的原因，最有可能的原因是压缩/垃圾收集代码尚未在服务器上运行。在某些情况下，您可能需要从运行服务器的任何人那里获得帮助。参见，例如，如何减少 Bitbucket 上的 git repo 大小？ 完整的细节很快就会深入到包文件格式、增量压缩窗口、替代对象目录的杂草中——像 GitHub 这样的站点广泛使用后者来防止分叉占用太多空间——等等。

¹这故意忽略了浅层或单分支克隆，它们在指定位置截断历史记录，因此省略了一些或许多提交和文件。

²实际上，Git 的许多内部文件都是纯文本的，但也有很多不是，而且在任何情况下，如果您要编写自己的代码来使用 Git，通常应该使用 Git 调用的管道命令来操作它们。使用提供的 API（管道命令）可以使您免受未来旨在使 Git 更好、更快地工作等的更改。

但是你的 .git 只是一个裸仓库

您将您的.git文件与他们的下载进行了比较。这些都不是或没有工作树，那么为什么你的.git目录更大？

现在我们必须进入那些杂草，至少一点点。

首先要知道的是，对于每个 Git对象，Git 有两种形式：每个提交、每个“blob”（文件）以及每个带注释的标签和树。其中之一是松散格式，它只是 zlib-deflated。另一个在压缩文件中，压缩程度更高。

当您在 Git 存储库中工作时，您会创建新的松散对象。Git 最终认为有太多松散对象占用了太多空间，并将它们打包。这使得它们的检索速度变慢——必须找到它们并拆开包装，而不是直接收集并重新充气——但现在它们占用的空间更少。

其次，每次在 Git 中执行操作时，都会添加新对象。其中一些永远不会被永久保存。这些（通常是松散的）对象被 Git 称为未引用：创建它们的目的是为了保存它们，至少是暂时的，也许是永久的，但后来证明它们是不必要的，所以它们只是被扔到了地板上。

除此之外，每次重新提交提交时，您实际上是在复制它们，然后放弃原始提交。但默认情况下，Git 会将原始文件保留至少 30 天，以防您改变主意并希望将其取回。它使用 Git 的reflogs来做到这一点。

这就是 Git 的“垃圾收集器”的git gc用武之地。垃圾收集器——Git 的死神，或者也许是死神收集器——有很多工作，包括找出 reflog 中哪些是老化的，应该被扔掉. 这可能会使更多的对象变得未被引用（除了那些被创建但最终证明是不需要的对象），所以它接下来会找到未被引用的松散对象并“修剪”它们。最后，它负责将松散的对象打包成较小（但访问速度较慢）的打包文件格式。

垃圾收集器会在需要时自动为您运行；您永远不必手动运行它。如果您必须手动运行它，这表明 Git 中存在某种错误（我已经阅读了一些这种情况，脚本会重载松散对象自动修剪）。请注意，这通常会将未引用的松散对象保留至少 14 天，以防万一仍在使它们被引用。

[编辑以添加我之前应该提到的最后两项：] 服务器通常git gc在每次推送后运行以进行打包和清理；并且可下载版本有时会在现场重新打包以使其尽可能小，或者至少尽可能小到“自动可能”（有时您可以通过调整gc参数使包文件更小，尽管当我第一次尝试时使用 Git，我不断地将它们变大 :-) )。