我有一个当地的回购。我用.git命令检查了du -csh <foldername>文件夹的大小。它是168 MB。我把它推到了我的bitbucket repo。我检查了回购的大小只有134 mb。
这怎么可能？
答案 0 :(得分：3)
首先，让我们解决整个存储库的大小问题。 （跳转到第二个标题部分以跳过此部分。）
一般而言，＆＃34;纯服务器＆＃34;存储库是Git称之为 bare 存储库的存储库，它们是没有工作树的存储库。
请记住，在任何 Git存储库中， 1 你有：
这些 2 都不具备您在计算机上正常使用的＆＃34;文件的形式＆＃34;，所以如果您计划做任何事情提交，除了将其发送给另一个Git之外，您可能需要一个工作树。服务器上的--bare存储库大多只是将提交转移到其他Gits（接收和发送），因此它浪费了空间，实际上适得其反，以保留当前提交的工作副本。
由于服务器省略了工作副本，因此通常应该期望服务器端裸存储库小于客户端非裸存储库。因此，您观察到的结果应该完全不足为奇。 令人惊讶的是，有时，服务器大小存储库更大。这有很多可能的原因，最可能的原因是压缩/垃圾收集代码尚未在服务器上运行。在某些情况下，您可能需要从运行服务器的任何人那里获得帮助。参见，例如，How to reduce git repo size on Bitbucket?完整的细节迅速深入到包文件格式的杂草，增量压缩窗口，备用对象目录 - 像GitHub这样的网站大量使用后者来保持分叉占用太多空间 - 所以上。
1 这故意忽略浅或单分支克隆，它会截断指定位置的历史记录，因此会省略一些或多个提交和文件。
2 实际上，很多Git的内部文件都是纯文本的，但很多都没有，而且无论如何你通常应该使用Git所谓的管道命令< / em>操纵它们，如果你要编写自己的代码来使用Git。使用提供的API - 管道命令 - 使您免受未来旨在使Git更好，更快等工作的更改。
您将.git文件与其下载进行了比较。这些都不是或者没有工作树，为什么你的.git目录更大？
现在我们必须进入那些杂草，至少一点点。
首先要知道的是，Git为每个Git 对象都有两种形式：每次提交，每次提交＆＃34; blob＆＃34; （文件），以及每个带注释的标签和树。其中一个是松散的格式，它只是zlib-deflated。另一个是包文件，它更加压缩。
当您在Git存储库中工作时，您将创建新的松散对象。 Git最终决定有太多松散的物体占用太多空间，并打包它们。这使得它们的检索速度变慢 - 它们必须被找到并解压缩，而不是直接收集并重新充气 - 但现在它们占用的空间更少。
其次，每次在Git中执行操作时，都会添加新对象。其中一些永远不会永久保存。这些（通常是松散的）对象是Git所谓的未引用的对象：它们是为了保存它们而制作的，至少有一段时间，也许是永久性的，但后来证明它们是不必要的，所以它们有刚落在地板上。
除此之外，每次你重新提交提交时，你实际上是复制它们，然后放弃原件。但是Git默认情况下会保留原件至少30天，以防你改变主意并希望他们回来。它使用Git的 reflogs 来完成此任务。
这就是Git＆＃34;垃圾收集器＆＃34;，git gc的用武之地。垃圾收集器--Git的死神，或者Grim Collector也许 - 有一些工作，包括弄清楚什么是老化的reflogs，应该被扔掉。这可能会使更多的对象变得未被引用（除了创建的任何对象，但最后都被证明是不需要的），因此它接下来会找到未引用的松散对象和＆＃34; prunes＆＃34;他们。最后，它将打包松散的对象转换为较小（但访问速度较慢）的包文件格式。
垃圾收集器会在需要时自动运行;你不应该有手动运行它。如果你必须手动运行它，这表明Git中存在各种错误（我已经阅读了一些这样的情况，脚本会使松散的对象自动修剪过载）。请注意，这通常会将未引用的松散物体留在周围至少14天，但是，如果某些东西仍在使它们被引用的话。
[编辑添加我之前应该提到的最后两项：]服务器通常运行git gc以在每次推送后打包和清理;并且可下载的版本有时会重新 - 在现场打包以使其尽可能小，或者至少小到可以自动实现＆＃34; （有时你可以通过调整gc参数来使包文件变得更小，尽管当我第一次尝试使用Git时，我不断改进它们:-)）。