man git-gc没有明显的答案，我也没有跟谷歌好运（虽然我可能刚刚使用了错误的搜索字词）。
我知道您应该偶尔在本地存储库上运行git gc来修剪悬空对象并压缩历史记录等等 - 但是这是一个容易受到同样问题影响的共享裸存储库吗？
如果重要的是，我们的工作流程是多个开发人员从共享网络驱动器上的裸存储库中取出并推送到该存储库。 “中央”存储库是使用git init --bare --shared创建的。
答案 0 :(得分：29)
对Jefromi发表评论，git gc 应在<正常“使用裸存储库时自动调用。
我刚刚在两个已经积极使用的裸共享存储库上运行git gc --aggressive;一个人在过去的3-4周内有大约38个提交，另一个在大约3个月内提交大约488个提交。没有人在任一存储库上手动运行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次提交）。
$ 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。但在阅读Dan's answer后，我注意到默认的松散对象限制是6700，我们显然还没有达到。
所以看起来结论是没有，你没有需要在裸仓库上手动运行git gc; * 但是使用gc.auto的默认设置，可能需要很长时间才能自动进行垃圾收集。
* 通常，您不需要运行git gc。但有时the manpage for git config您应该手动运行git gc或将gc.auto设置为较低的值。然而，我对这个问题的理由是简单的好奇心。
答案 1 :(得分：14)
来自git-gc手册页：
鼓励用户定期在中执行此任务 存储库，以保持良好的磁盘空间利用率和良好的运行 性能
强调我的。裸存储库也是存储库！
进一步说明：git-gc执行的其中一项内务处理任务是打包和重新打包松散的对象。即使你的裸存储库中没有任何悬空对象，你也会 - 随着时间的推移 - 积累大量松散的对象。为了提高效率，这些松散的物体应定期包装。同样，如果大量的包积累，它们应该定期重新包装成更大（更少）的包。
答案 2 :(得分：2)
git gc --auto的问题在于它可以阻止。
但是使用新的（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。
注意：只有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：从守护进程gc --auto保存日志并在下次打印虽然commit 9f673f9（
gc：在后台运行--auto的配置选项 - 2014-02-08）有助于减少一些有关＆＃39;gc --auto＆＃的投诉39;占用终端，会产生另一套问题。此套装中的最新版本是，作为守护程序的结果，
stderr已关闭，所有警告都将丢失。cmd_gc()结尾处的此警告特别重要，因为它告诉用户如何避免＆＃34;gc --auto＆＃34;反复跑步 由于stderr关闭，用户不知道，他们自然会抱怨＆＃39;gc --auto＆＃39;浪费CPU。守护
gc现在将stderr保存到$GIT_DIR/gc.log。
在用户删除gc --auto之前，gc.log将无法投放并gc.log打印出来。
答案 3 :(得分：1)
有些操作会自动运行git gc --auto，因此不应该需要来运行git gc，git应该自行处理。
与bwawok所说的相反，实际上（或者可能是）你的本地回购与之间存在差异：你用它做什么操作。例如，可以通过rebase创建悬空对象，但是你可能永远不会重新设置裸仓库，所以也许你不需要删除它们（因为从来没有）。因此，您可能不需要经常使用git gc。但话说回来，就像我说的那样，git应该自动处理这个问题。
答案 4 :(得分：0)
我不知道100％关于gc的逻辑......但是要说明这一点：
git gc删除了额外的历史垃圾，压缩了额外的历史记录等。它对您的本地文件副本没有任何作用。
裸仓和普通仓库之间的唯一区别是，如果您有本地文件副本。
所以，我认为是的，你应该在一个裸仓库上运行git gc。
我从来没有亲自跑过，但我的回购很小，而且还很快。