我是否需要在裸回购版上运行git gc？
man git-gc没有明显的答案，我也没有与Google有过任何运气（尽管我可能刚刚使用了错误的搜索条件）。
我知道您应该偶尔在本地存储库上运行git gc以修剪悬空对象和压缩历史记录等，但这是一个共享的裸存储库，容易受到这些相同的问题影响？
如果重要的话，我们的工作流程是多个开发人员从共享网络驱动器上拉出并推送到裸存储库。 “中央”仓库是用git init --bare --shared创建的。
当Jefromi评论Dan的回答时，应该在“正常”使用裸仓库时自动调用git gc 。
我刚刚在两个已被积极使用的裸露共享存储库上运行git gc --aggressive ; 其中约38人在过去的3-4周内提交，另外约388人在约3个月内提交。 没有人在任何一个版本库上手动运行git gc 。
较小的存储库
$ git count-objects
333 objects, 595 kilobytes
$ git count-objects -v
count: 333
size: 595
in-pack: 0
packs: 0
size-pack: 0
prune-packable: 0
garbage: 0
$ git gc --aggressive
Counting objects: 325, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (323/323), done.
Writing objects: 100% (325/325), done.
Total 325 (delta 209), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
$ git count-objects -v
count: 8
size: 6
in-pack: 325
packs: 1
size-pack: 324
prune-packable: 0
garbage: 0
$ git count-objects
8 objects, 6 kilobytes
更大的存储库
$ git count-objects
4315 objects, 11483 kilobytes
$ git count-objects -v
count: 4315
size: 11483
in-pack: 9778
packs: 20
size-pack: 15726
prune-packable: 1395
garbage: 0
$ git gc --aggressive
Counting objects: 8548, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8468/8468), done.
Writing objects: 100% (8548/8548), done.
Total 8548 (delta 7007), reused 0 (delta 0)
Removing duplicate objects: 100% (256/256), done.
$ git count-objects -v
count: 0
size: 0
in-pack: 8548
packs: 1
size-pack: 8937
prune-packable: 0
garbage: 0
$ git count-objects
0 objects, 0 kilobytes
我希望我已经想到这一点之前，我gc编这两个仓库，但我应该运行git gc没有--aggressive选项，看到了差距。 幸运的是，我有一个中型活动存储库可供测试（164个提交近2个月）。
$ git count-objects -v
count: 1279
size: 1574
in-pack: 2078
packs: 6
size-pack: 2080
prune-packable: 607
garbage: 0
$ git gc
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1073/1073), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1210), reused 1050 (delta 669)
Removing duplicate objects: 100% (256/256), done.
$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1092
prune-packable: 0
garbage: 0
$ git gc --aggressive
Counting objects: 1772, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (1742/1742), done.
Writing objects: 100% (1772/1772), done.
Total 1772 (delta 1249), reused 0 (delta 0)
$ git count-objects -v
count: 0
size: 0
in-pack: 1772
packs: 1
size-pack: 1058
prune-packable: 0
garbage: 0
运行git gc显然在count-objects造成了很大的负担，即使我们经常push并从这个存储库中fetch 。 但是在阅读git config的manpage后，我发现默认的松散对象限制是6700，我们显然还没有达到。
因此，看起来结论是否定的 ，你不需要在裸gc.auto手动运行git gc ;但是对于gc.auto的默认设置，它可能需要很长时间才能自动进行垃圾回收。
*通常，你不需要运行git gc 。 但有时你可能会被绑在空间上，你应该手动运行git gc或者将gc.auto设置为较低的值。 但是，我的问题是简单的好奇心。
从git-gc手册页：
鼓励用户在每个存储库中定期运行此任务，以保持良好的磁盘空间利用率和良好的操作性能。
强调我的。 裸存储库也是存储库！
进一步解释： git-gc执行的一项内务任务是对松散物体进行打包和重新包装。 即使你的裸仓库中没有任何悬挂的物体，你也会 - 随着时间的推移 - 积聚大量的松散物体。 这些松散的物体应定期打包，以提高效率。 同样，如果大量包装积累，它们应定期重新包装成更大（更少）的包装。
git gc --auto的问题是它可能被阻塞。
但随着新的（Git 2.0 Q2 2014）设置gc.autodetach ，您现在可以不受任何干扰地完成：
参见提交4c4ac4d和提交9f673f9（NguyễnTháiNgọcDuy，又名pclouds）：
gc --auto需要时间并且可以暂时阻止用户（但不会那么烦人）。
让它在支持它的系统上运行。
在后台运行丢失的唯一东西是打印输出。 但gc output并不是很有趣。
您可以通过更改gc.autodetach将其保留在前景中。
注意：只有git 2.7（Q4 2015）将确保不会丢失错误消息 。
参见NguyễnTháiNgọcDuy（ pclouds ）的commit 329e6e8（2015年9月19日）。
（由Junio C gitster合并 - gitster - 在提交076c827，2015年10月15日）
gc ：从daemonized gc --auto保存日志并在下次打印
虽然提交9f673f9（ gc ：config选项用于在后台运行--auto - 2014-02-08）有助于减少有关' gc --auto '占用终端的一些抱怨，但它会产生另一组问题。
作为守护进程的结果，这组中的最新版本是， stderr已关闭，所有警告均已丢失。 cmd_gc()结尾处的警告特别重要，因为它告诉用户如何避免“ gc --auto ”重复运行。
由于stderr已关闭，用户不知道，自然他们抱怨' gc --auto '浪费CPU。
守护进程gc现在将stderr保存到$GIT_DIR/gc.log 。
以下gc --auto将不会运行，并且gc.log打印出来，直到用户删除gc.log 。