man git-gc里面没有明显的答案，而且我在谷歌上也没有运气（尽管我可能只是使用了错误的搜索词）。
我知道您应该偶尔git gc在本地存储库上运行以修剪悬空对象和压缩历史记录等 - 但是共享裸存储库是否容易受到这些相同问题的影响？
如果重要的话，我们的工作流程是多个开发人员从共享网络驱动器上的裸存储库中提取和推送。“中央”存储库是用git init --bare --shared.
问问题
18888 次
5 回答
34
正如Jefromi对Dan 的回答所评论的那样，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以查看差异。幸运的是，我还有一个中等规模的活动存储库需要测试（近 2 个月内提交了 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显然对. 但是在阅读手册页时，我注意到默认的松散对象限制是 6700，我们显然还没有达到。count-objectspushfetchgit config
所以看起来结论是否定的，你不需要在git gc一个裸仓库上手动运行；*但使用 的默认设置gc.auto，可能需要很长时间才能自动进行垃圾收集。
* 通常，您不需要运行git gc. 但有时您可能会受到空间的限制，您应该git gc手动运行或设置gc.auto为较低的值。不过，我对这个问题的看法很简单。
于 2011-01-03T21:11:29.293 回答
16
从git-gc手册页：
鼓励用户在每个存储库中定期运行此任务，以保持良好的磁盘空间利用率和良好的运行性能。
强调我的。裸仓库也是仓库！
进一步解释：git-gc执行的内务管理任务之一是打包和重新打包松散的物品。即使您的裸存储库中从未有任何悬空对象，随着时间的推移，您也会积累大量松散的对象。为了提高效率，这些松散的对象应该定期打包。同样，如果大量包装堆积，它们应该定期重新包装成更大（更少）的包装。
于 2010-08-20T16:55:26.630 回答
2
问题git gc --auto在于它可能会阻塞。
但是使用新的 (Git 2.0 Q2 2014) 设置gc.autodetach，您现在可以在没有任何中断的情况下执行此操作：
请参阅提交 4c4ac4d和提交 9f673f9（Nguyễn Thái Ngọc Duy，又名 pclouds）：
gc --auto需要时间并且可以暂时阻止用户（但同样令人讨厌）。
让它在支持它的系统上在后台运行。
在后台运行时唯一丢失的是打印输出。但gc output并不是很有趣。
您可以通过更改将其保持在前台gc.autodetach。
注意：只有 git 2.7 (Q4 2015) 才能确保不会丢失错误消息。
请参阅Nguyễn Thái Ngọc Duy ( )的提交 329e6e8（2015 年 9 月 19 日） 。（由Junio C Hamano 合并 -- --在提交 076c827中，2015 年 10 月 15 日）pclouds
gitster
gc: 从守护进程中保存日志gc --auto并在下次打印虽然提交 9f673f9（
gc：用于在后台运行的配置选项--auto- 2014-02-08）有助于减少一些关于“”占用终端的抱怨gc --auto，但它会产生另一组问题。由于守护进程，该集合中的最新版本
stderr已关闭，并且所有警告都丢失了。这个末尾的警告cmd_gc()特别重要，因为它告诉用户如何避免“gc --auto”重复运行。
因为stderr是关闭的，用户不知道，自然会抱怨'gc --auto'浪费CPU。Daemonized
gc现在保存stderr到$GIT_DIR/gc.log. 在用户删除之前，
Followinggc --auto不会运行并gc.loggc.log打印出来。
于 2014-03-12T16:40:49.770 回答
1
有些操作会git gc --auto自动运行，所以永远不需要运行git gc，git 应该自己处理。
与 bwawok 所说的相反，您的本地存储库和裸机存储库之间实际上存在（或可能存在）差异：您用它做什么操作。例如，悬空对象可以通过变基来创建，但您可能永远不会变基裸仓库，所以也许您不需要删除它们（因为从来没有）。因此，您可能不需要git gc经常使用它。但话又说回来，就像我说的，git 应该自动处理这个问题。
于 2010-08-20T16:46:33.307 回答
0
我对 gc 的逻辑不是 100% 了解 .. 但要对此进行推理：
git gc 删除了额外的历史垃圾，压缩了额外的历史等。它对您的本地文件副本没有任何作用。
裸仓库和普通仓库之间的唯一区别是您是否拥有文件的本地副本。
所以，我认为有理由认为是的，你应该在一个裸仓库上运行 git gc 。
我从来没有亲自运行过它，但是我的仓库很小而且仍然很快。
于 2010-08-20T16:19:32.607 回答