这主要取决于存储库的使用量。有了一个用户每天签入一次，每周进行一次分支/合并等操作，你可能不需要一年运行它超过一次。

由于几十个开发人员在几十个项目中工作，每个人每天检查2-3次，您可能希望每晚运行它。

不过，比实际需要更频繁地运行它也无妨。

我要做的是现在运行它，然后一周后测量磁盘利用率，再次运行它，并再次测量磁盘利用率。如果它的大小下降了5%，那么每周运行一次。如果它下降更多，那么更频繁地运行它。如果它下降较少，那么运行频率就会降低。

请注意，对存储库进行垃圾收集的缺点是，垃圾会被收集。作为计算机用户，我们都知道，我们现在认为是垃圾的文件在未来三天可能会变得非常有价值。git保留了大部分碎片，这一事实多次为我节省了精力——通过浏览所有悬垂的提交，我恢复了许多我不小心封存的工作。

所以在你的私人克隆中不要太洁癖。没有什么必要。

此外，数据可恢复性的价值是值得怀疑的回购主要用作远程，如。这是所有开发者前进和/或前进的地方。在那里，启动GC运行和频繁重新打包可能是明智的。

这主要取决于存储库的使用量。有了一个用户每天签入一次，每周进行一次分支/合并等操作，你可能不需要一年运行它超过一次。

由于几十个开发人员在几十个项目中工作，每个人每天检查2-3次，您可能希望每晚运行它。

不过，比实际需要更频繁地运行它也无妨。

我要做的是现在运行它，然后一周后测量磁盘利用率，再次运行它，并再次测量磁盘利用率。如果它的大小下降了5%，那么每周运行一次。如果它下降更多，那么更频繁地运行它。如果它下降较少，那么运行频率就会降低。

当我做一个大的提交时，尤其是当我从存储库中删除更多的文件时。之后，提交速度更快

如果你在使用Git-Gui，它会告诉你什么时候应该担心:

这个存储库目前大约有1500个松散对象。

下面的命令会得到一个类似的数字:

$ git count-objects

除了，从它的源代码，git-gui将自己进行数学计算，实际上在.git/objects文件夹中计算一些东西，并可能带来一个近似值(我不知道tcl能正确读取它!)

无论如何，它给出的警告似乎是基于大约300个松散物体的任意数字。

将它放到一个每天晚上(下午?)当您睡觉时运行的cron作业中。