git本地存储库大小和子文件夹大小差异太大

我是git和github的新手，我对github存储库的大小有一些疑问：

我在github上的存储库大小为

本地存储库目录的大小为42.1M

我的问题是，为什么本地存储库中所有子目录的大小都是

---

我试图通过git gc解决，但没有成功，我甚至想知道这是否是个问题，不知道，有人知道吗？谢谢。

工作树的大小相对于repo中数据库的大小可能会因许多原因而有所不同

一方面，使用增量对存储库进行打包、压缩和优化。另一方面，这些技术的有效性因内容而异，repo包含您的所有历史记录，而您的工作树只包含一个版本（在任何给定时间）

关于

gc

，它所做的主要工作是从repo中删除无法访问的对象。例如，如果您在一个分支上工作了一段时间，可能会添加一些大型二进制资产，但稍后会删除它们；然后，您以这样一种方式重新设置分支的基础，即新的历史记录根本不显示大型二进制资产。。。最终，

gc

应该删除原始提交和大型二进制资产，回收一些空间

但是“不可到达”不仅意味着没有裁判可以到达它，还意味着reflog无法到达它。如果您希望确保回收所有未使用的空间（并且您确信不需要从reflog恢复任何内容），那么您可以清除reflog，然后运行“积极”gc

作为对那一点的旁白。。。从理论上讲，消除回流是很容易的

git reflog expire --expire=now

但我看到这无法删除reflog条目，我真的不知道为什么。可以删除实际的日志文件（例如，在bash中使用

rm

），但要小心；如果您有任何藏品，它们也会记录在.git/logs下，您可能不想破坏它们

repo（在.git文件夹中测量）与工作树的相对大小也可能受到是否使用LFS的影响。我不确定LFS存储将如何反映在github的大小报告中

---

如果你已经用

gc

回收了所有你能回收的空间，而LFS不是一个因素，那么我会说10:1的比例对我来说似乎很奇怪；但是，如果您的历史记录中有很多二进制文件发生了变化，这也不是不可能的。

使用BFG Repo Cleaner？我不知道我是否使用得不正确或没有效果，也许更重要的是，如果您添加了一个大文件，然后将其删除，即使你不记得为什么，这仍然在历史中。Per@JoshLee：如果对象在可访问的历史中被引用，那么他说的是真的。（如果没有看到我在上面对

gc

的评论。）如果在可访问的历史记录中有一个大型资产，如果它导致了问题，您可以使用BFG回购清理器（或者

git——过滤器分支

，如果您有耐心并准备接受挑战）将其删除或将其转换为LFS对象。感谢您的详细解释，这个repo对很多文件进行了删除和添加操作，文件可能比较多，但文件不是太大，我尝试了以下命令：

$git gc--prune=now--aggressive

，运气不好，没有效果