我是否需要在裸回购版上运行git gc？
man git-gc没有一个明显的答案，我也没有与谷歌运气（虽然我可能刚刚使用了错误的search条件）。
我知道你应该偶尔在本地存储库上运行git gc来修剪悬挂的对象和压缩历史logging等，但是这是一个共享的裸存储库，容易受到这些相同的问题的影响？
如果重要的话，我们的工作stream程是多个开发人员从共享networking驱动器上拉出并推送到裸存储库。 “中央”仓库是用git init --bare --shared创build的。
当Jefromi评论Dan的回答时 ， 应该在“正常”使用裸仓库时自动调用git gc 。
我只是在两个已经被积极使用的裸露的，共享的仓库上运行git gc --aggressive 。 其中约38人承诺过去3-4周，另外约488人承诺约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
我希望在使用这两个版本库之前，我已经想到了它，但是我应该运行git gc 而不使用--aggressive选项来查看差异。 幸运的是我有一个中型的活动存储库可供testing（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造成很大的负担，即使我们经常从这个仓库中fetch和fetch 。 但是在阅读git config的manpage后 ，我发现默认的松散对象限制是6700，我们显然还没有达到。
所以看来结论是否定的 ，你不需要在裸回购上手动运行git gc ; *但使用gc.auto的默认设置，可能需要很长时间才能自动进行垃圾回收。
* 通常 ，你不需要运行git gc 。 但有时你可能会被束缚在空间中 ，你应该手动运行git gc或将gc.auto设置为较低的值。 但是，我的问题是简单的好奇心。
从git-gc手册页：
鼓励用户在每个存储库中定期运行此任务，以保持良好的磁盘空间利用率和良好的操作性能。
强调我的。 裸存储库也是存储库！
进一步解释： git-gc执行的一项内务任务是对松散物体进行打包和重新包装 。 即使你的仓库里没有任何悬挂的东西，你也会随着时间的推移积累大量的松散的东西。 这些松散的物体应定期打包，以提高效率。 同样，如果大量包装积累，他们应定期重新包装成更大（更less）的包装。
有些操作会自动运行git gc --auto ，所以不应该需要运行git gc ，git应该自己处理这个问题。
与bwawok所说的相反，你的本地回购实际上存在（或可能是）一个区别，那就是：你用它做什么操作。 例如，可以通过重新绑定来创build悬挂对象，但是也可以不重新绑定裸露的repo，所以也许你永远不需要去除它们（因为从来没有）。 因此，你可能不需要经常使用git gc 。 但是，就像我说的那样，git应该自动处理这个问题。
与git gc --auto的问题是，它可以阻止。
但随着新的（Git 2.0 Q2 2014）设置gc.autodetach ，你现在可以做到这一点，没有任何中断：
参见提交4c4ac4d并提交9f673f9 （ NguyễnTháiNgọcDuy，aka 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：从daemonizedgc --auto保存日志，下次打印虽然提交9f673f9 （
gc：config选项用于在后台运行--auto– 2014-02-08）有助于减less有关gc --auto占用terminal的一些抱怨，但会产生另一组问题。这个集合中最新的是，由于守护进程的结果，
stderr被closures，所有的警告都失去了。cmd_gc()结束时的警告特别重要，因为它告诉用户如何避免“gc --auto”重复运行。
由于stderrclosures，用户不知道，自然他们抱怨'gc --auto'浪费CPU。守护进程
gc现在将stderr保存到$GIT_DIR/gc.log。
以下gc --auto将不会运行，并且gc.log打印出来，直到用户删除gc.log。
我不知道gc的逻辑是100％，但推理了这一点：
git gc删除了额外的历史垃圾，压缩额外的历史，等等。它与你的本地文件副本没有任何关系。
裸和正常回购之间唯一的区别是如果你有本地的文件副本。
所以，我认为这是肯定的，你应该运行git gc裸回购。
我从来没有亲自跑过，但是我的回购很小，而且还很快。
