应该多久使用一次git-gc?
手册页简单地说:
鼓励用户在每个存储库中定期运行此任务，以保持良好的磁盘空间利用率和良好的操作性能。
是否有一些命令来获取一些对象计数，以确定是否到了gc的时候?
这主要取决于存储库的使用量。有了一个用户每天签入一次，每周进行一次分支/合并等操作，你可能不需要一年运行它超过一次。
由于几十个开发人员在几十个项目中工作，每个人每天检查2-3次，您可能希望每晚运行它。
不过，比实际需要更频繁地运行它也无妨。
我要做的是现在运行它，然后一周后测量磁盘利用率，再次运行它，并再次测量磁盘利用率。如果它的大小下降了5%，那么每周运行一次。如果它下降更多，那么更频繁地运行它。如果它下降较少，那么运行频率就会降低。
将它放到一个每天晚上(下午?)当您睡觉时运行的cron作业中。
我使用git gc后，我做了一个大的签出，并有很多新对象。它可以节省空间。例如，如果您使用git- SVN签出一个大型SVN项目，并执行git gc，通常可以节省大量空间
最新版本的git在需要时自动运行gc，所以你不需要做任何事情。参见男人git-gc (1)的Options部分:“一些git命令在执行可能创建许多松散对象的操作后运行git gc——auto。”
请注意，对存储库进行垃圾收集的缺点是，垃圾会被收集。作为计算机用户，我们都知道，我们现在认为是垃圾的文件在未来三天可能会变得非常有价值。git保留了大部分碎片，这一事实多次为我节省了精力——通过浏览所有悬垂的提交，我恢复了许多我不小心封存的工作。
所以在你的私人克隆中不要太洁癖。没有什么必要。
此外，数据可恢复性的价值是值得怀疑的回购主要用作远程，如。这是所有开发者前进和/或前进的地方。在那里，启动GC运行和频繁重新打包可能是明智的。
如果你正在使用< >强Git-Gui < / >强，它会在你应该担心的时候告诉你:
This repository currently has approximately 1500 loose objects.
下面的命令会得到一个类似的数字:
$ git count-objects
除了从源头看, git-gui会自己做数学运算，实际上在.git/objects文件夹中计算一些东西，并可能带来一个近似值(我不知道tcl能正确地读取它!)
.git/objects
tcl
在任何情况下，它似乎基于任意数字周围 300松散对象给出警告。
你可以不受任何干扰，使用新的(Git 2.0 Q2 2014)设置< >强gc.autodetach < / >强。
gc.autodetach
参见提交4 c4ac4d和提交9 f673f9 (nguy拘Thái ngeconc Duy，又名pclouds):
gc --auto需要时间，可以暂时阻止用户(但并不会减少恼人的) 让它在支持它的系统后台运行 在后台运行唯一丢失的是打印输出。但是gc output并不是真的有趣 你可以通过改变gc.autodetach来保持它在前台
gc --auto
gc output
pclouds
gitster
gc:从daemonized gc --auto保存日志，下次打印 虽然提交9 f673f9 (gc: config选项，用于在后台运行--auto - 2014-02-08)有助于减少一些关于'gc --auto'占用终端的抱怨，但它产生了另一组问题。 这个集合中最新的是，由于daemonizing的结果，stderr被关闭，所有的警告都丢失了。cmd_gc()结尾的警告特别重要，因为它告诉用户如何避免"gc --auto"重复运行 因为stderr是关闭的，用户不知道，自然他们抱怨'gc --auto'浪费CPU Daemonized gc现在保存stderr到$GIT_DIR/gc.log 在用户删除gc.log. . 0之前，gc --auto将不会运行并打印出gc.log
gc
虽然提交9 f673f9 (gc: config选项，用于在后台运行--auto - 2014-02-08)有助于减少一些关于'gc --auto'占用终端的抱怨，但它产生了另一组问题。
--auto
这个集合中最新的是，由于daemonizing的结果，stderr被关闭，所有的警告都丢失了。cmd_gc()结尾的警告特别重要，因为它告诉用户如何避免"gc --auto"重复运行 因为stderr是关闭的，用户不知道，自然他们抱怨'gc --auto'浪费CPU
stderr
cmd_gc()
Daemonized gc现在保存stderr到$GIT_DIR/gc.log 在用户删除gc.log.
$GIT_DIR/gc.log
gc.log
当我做一个大的提交时，尤其是当我从存储库中删除更多的文件时。之后，提交速度更快
这句话摘自; Git版本控制 < / p >
Git自动运行垃圾收集: •如果存储库中有太多松散对象 •当推送到远程存储库时 •在一些可能引入许多松散对象的命令之后 •当一些命令，如git reflog expire显式请求它 最后，当您显式地请求它时，将发生垃圾收集 使用git gc命令。但那应该是什么时候呢?没有固体 回答这个问题，但有一些好的建议和最好的 练习。< / p > 你应该考虑在几分钟内手动运行git gc 情况:< /强> < / p > •如果你刚刚完成了一个git过滤器分支。回想一下, 过滤器分支重写许多提交，引入新的提交，然后离开 当你满意的时候，旧的参考应该被删除 结果。所有那些死亡的物体(不再存在) 引用，因为你只是删除了一个引用指向他们) •在一些可能引入许多松散对象的命令之后。这 例如，可能是一个大的rebase工作 另一方面， 什么时候应该警惕垃圾收集?< /强> < / p > •如果有孤儿裁判，你可能想要恢复 •在git的上下文中，您不需要保存 决议永远< / p > •在只有标签和分支足以引起 Git永久保留提交 •在FETCH_HEAD检索上下文中(url直接检索通过 Git取回)，因为它们立即受制于垃圾回收
Git自动运行垃圾收集:
•如果存储库中有太多松散对象
•当推送到远程存储库时
•在一些可能引入许多松散对象的命令之后
•当一些命令，如git reflog expire显式请求它
最后，当您显式地请求它时，将发生垃圾收集 使用git gc命令。但那应该是什么时候呢?没有固体 回答这个问题，但有一些好的建议和最好的 练习。< / p > 你应该考虑在几分钟内手动运行git gc 情况:< /强> < / p >
•如果你刚刚完成了一个git过滤器分支。回想一下, 过滤器分支重写许多提交，引入新的提交，然后离开 当你满意的时候，旧的参考应该被删除 结果。所有那些死亡的物体(不再存在) 引用，因为你只是删除了一个引用指向他们)
•在一些可能引入许多松散对象的命令之后。这 例如，可能是一个大的rebase工作
另一方面， 什么时候应该警惕垃圾收集?< /强> < / p > •如果有孤儿裁判，你可能想要恢复 •在git的上下文中，您不需要保存 决议永远< / p > •在只有标签和分支足以引起 Git永久保留提交 •在FETCH_HEAD检索上下文中(url直接检索通过 Git取回)，因为它们立即受制于垃圾回收
•如果有孤儿裁判，你可能想要恢复
•在git的上下文中，您不需要保存 决议永远< / p >
•在只有标签和分支足以引起 Git永久保留提交
•在FETCH_HEAD检索上下文中(url直接检索通过 Git取回)，因为它们立即受制于垃圾回收
你不需要经常使用git gc，因为git gc(垃圾收集)在几个常用的命令上自动运行:
git gc
git pull git merge git rebase git commit
来源:git gc最佳实践和常见问题解答
