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

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

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

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

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

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

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

这句话摘自; Git版本控制

Git runs garbage collection automatically: • If there are too many loose objects in the repository • When a push to a remote repository happens • After some commands that might introduce many loose objects • When some commands such as git reflog expire explicitly request it And finally, garbage collection occurs when you explicitly request it using the git gc command. But when should that be? There’s no solid answer to this question, but there is some good advice and best practice. You should consider running git gc manually in a few situations: • If you have just completed a git filter-branch . Recall that filter-branch rewrites many commits, introduces new ones, and leaves the old ones on a ref that should be removed when you are satisfied with the results. All those dead objects (that are no longer referenced since you just removed the one ref pointing to them) should be removed via garbage collection. • After some commands that might introduce many loose objects. This might be a large rebase effort, for example. And on the flip side, when should you be wary of garbage collection? • If there are orphaned refs that you might want to recover • In the context of git rerere and you do not need to save the resolutions forever • In the context of only tags and branches being sufficient to cause Git to retain a commit permanently • In the context of FETCH_HEAD retrievals (URL-direct retrievals via git fetch ) because they are immediately subject to garbage collection

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

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

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

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

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

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

$ git count-objects

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

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

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