你应该多久使用一次git-gc？
manual page简单地说：
建议用户定期在每个存储库中运行此任务，以保持良好的磁盘空间利用率和良好的运行性能。
是否有一些命令来获取一些对象计数，以确定是否需要gc的时间？
这主要取决于存储库的使用量。一个用户每天检查一次，每周一次分支/合并/等操作，您可能不需要每年运行一次以上。
有几十个开发人员正在处理几十个项目，每个项目每天检查2-3次，您可能希望每晚运行它。
但是，运行它的频率不会超过需要。
我现在要做的就是现在运行它，然后一周后测量磁盘利用率，再次运行它，并再次测量磁盘利用率。如果它的尺寸下降了5％，那么每周运行一次。如果它下降更多，则更频繁地运行它。如果它减少了，那么不那么频繁地运行它。
请注意，垃圾收集存储库的缺点是收集垃圾。众所周知，作为计算机用户，我们现在认为垃圾的文件可能会在未来三天变得非常有价值。 git保留了大部分碎片的事实已经多次保存我的培根 - 通过浏览所有悬挂的提交，我已经恢复了很多我意外罐装的工作。
因此，不要在你的私人克隆中做太多整洁的怪物。几乎没有必要。
OTOH，数据可恢复性的价值对于主要用作遥控器的repos是有问题的，例如。所有开发者推动和/或拉动的地方。在那里，开始GC运行和频繁重新包装可能是明智的。
最新版本的git会在需要时自动运行gc，因此您不必执行任何操作。请参阅man git-gc(1)的Options部分：“执行可能会创建许多松散对象的操作后，某些git命令会运行git gc --auto。”
如果您正在使用Git-Gui，那么当您应该担心时，它会tells you：
This repository currently has approximately 1500 loose objects.
以下命令将带来一个类似的数字：
$ git count-objects
除了，from its source，git-gui将自己做数学，实际上在.git/objects文件夹中计算一些东西并且可能带来近似值（我不知道tcl正确读取它！）。
在任何情况下，它似乎都会根据大约300个松散物体的任意数字给出警告。
把它放在一个每天晚上（下午？）睡觉的cron工作中。
我做了大量结账后使用git gc，并且有很多新对象。它可以节省空间。例如。如果您使用git-svn签出一个大型SVN项目，并执行git gc，通常可以节省大量空间
您可以在没有任何中断的情况下使用新的（Git 2.0 Q2 2014）设置gc.autodetach。
见commit 4c4ac4d和commit 9f673f9（Nguyễn Thái Ngọc Duy, aka pclouds）：
gc --auto需要时间并且可以暂时阻止用户（但不会那么烦人）。 使其在支持它的系统的后台运行。 在后台运行时唯一丢失的是打印输出。但gc output并不是很有趣。 您可以通过更改gc.autodetach将其保持在前景中。
从2.0发布以来，虽然有一个bug：git 2.7（2015年第4季度）将确保不会丢失错误消息。
请参阅commit 329e6e8撰写的Nguyễn Thái Ngọc Duy (pclouds)（2015年9月19日）。
（Junio C Hamano -- gitster --在commit 076c827合并，2015年10月15日）
gc：从daemonizedgc --auto保存日志并在下次打印虽然commit 9f673f9（
gc：在背景中运行--auto的配置选项 - 2014-02-08）有助于减少一些关于'gc --auto'占用终端的投诉，但它会产生另一组问题。这一组中的最新内容是，由于守护进程，
stderr已关闭，所有警告都将丢失。在cmd_gc()结束时的这个警告特别重要，因为它告诉用户如何避免“gc --auto”反复运行。 因为stderr关闭了，用户不知道，他们自然会抱怨'gc --auto'浪费CPU。Daemonized
gc现在将stderr保存到$GIT_DIR/gc.log。 以下gc --auto将不会运行和gc.log打印出来，直到用户删除gc.log。
这句话取自; Version Control with Git
Git自动运行垃圾收集：
•如果存储库中有太多松散的对象
•发生推送到远程存储库时
•在一些可能引入许多松散对象的命令之后
•当某些命令（例如git reflog）到期时明确请求它
最后，当您使用git gc命令显式请求时，会发生垃圾收集。但什么时候应该呢？这个问题没有可靠的答案，但有一些好的建议和最佳实践。
你应该考虑在几种情况下手动运行git gc：
•如果您刚刚完成了git过滤器分支。回想一下，filter-branch重写了许多提交，引入了新的提交，并将旧的提交保留在ref上，当你对结果感到满意时应该删除它。应该通过垃圾收集删除所有那些死对象（因为你刚刚删除指向它们的一个引用而不再引用它们）。
•在一些可能引入许多松散对象的命令之后。例如，这可能是一个很大的变革努力。
另一方面，你什么时候应该警惕垃圾收集？
•如果存在您可能想要恢复的孤立引用
•在git rerere的上下文中，您不需要永久保存分辨率
•仅在标记和分支足以导致Git永久保留提交的上下文中
•在FETCH_HEAD检索（通过git fetch进行URL直接检索）的上下文中，因为它们立即受到垃圾回收
•仅在标记和分支足以导致Git永久保留提交的上下文中
•在FETCH_HEAD检索（通过git fetch进行URL直接检索）的上下文中，因为它们立即受到垃圾回收
我在进行大提交时使用，最重要的是当我从存储库中删除更多文件时...之后，提交速度更快