你应该多久使用一次 git-gc ？

Question

你应该多久使用一次 git-gc ？

手册页简单地说：

鼓励用户在每个存储库中定期运行此任务，以保持良好的磁盘空间利用率和良好的操作性能。

是否有一些命令可以获取一些对象计数以了解是否到了 gc 的时间？

Answer 1

这主要取决于存储库的使用量。 如果一个用户每天签入一次，每周一次分支/合并/等操作，您可能不需要每年运行一次以上。

由于数十名开发人员正在处理数十个项目，每个项目每天检查 2-3 次，您可能希望每晚运行它。

不过，比需要的频率更频繁地运行它并没有什么坏处。

我要做的就是现在运行它，然后一周后测量磁盘利用率，再次运行它，并再次测量磁盘利用率。 如果大小下降 5%，则每周运行一次。 如果下降更多，则更频繁地运行。 如果下降较少，则减少运行频率。

Answer 2

最新版本的 git 会在需要时自动运行 gc，因此您不必执行任何操作。 请参阅 man git-gc(1 )：“某些 git 命令在执行可能创建许多松散对象的操作后运行 git gc --auto。”

Answer 3

如果您使用 Git-Gui，则 告诉您何时应该担心：

此存储库当前拥有大约 1500 个松散对象。 
  

以下命令将带来类似的数字：

$ git count-objects

除了， 来自其来源，git-gui 会自己进行数学计算，实际上是在 .git/objects 文件夹中计算一些内容，并且可能会带来一个近似值（我不知道 tcl 是否正确）读一下！）。

无论如何，它似乎都会根据大约 300 个松散物体的任意数量发出警告。

Answer 4

将其放入每晚（下午？）当你睡觉时运行的 cron 作业中。

Answer 5

您可以使用新的 (Git 2.0 Q2 2014) 设置 gc.autodetach。

请参阅 提交 4c4ac4d 和 提交 9f673f9 (Nguyễn Thái Ngọc Duy，又名 pcloud s ):

gc --auto 需要时间并且可能会暂时阻止用户（但同样令人烦恼）。
使其在支持它的系统上在后台运行。
在后台运行唯一丢失的是打印输出。 但gc 输出并不是很有趣。
您可以通过更改 gc.autodetach 将其保留在前台。

---

自 2.0 版本以来，存在一个错误：git 2.7（2015 年第 4 季度）将确保不会丢失错误消息。
请参阅 提交 329e6e8（2015 年 9 月 19 日），作者：Nguyễn Thái Ngọc Duy (pclouds)。
^{（由 Junio C Hamano -- gitster -- 合并于 提交 076c827，2015 年 10 月 15 日）}

gc：保存来自守护进程gc --auto的日志并在下次打印

虽然提交9f673f9（gc：配置选项在后台运行 --auto - 2014-02-08）有助于减少一些关于“gc --auto”占用终端的投诉，但它会产生另一组问题。

这组中的最新情况是，由于守护进程，stderr 被关闭，所有警告都丢失。 cmd_gc() 末尾的警告特别重要，因为它告诉用户如何避免“gc --auto”重复运行。
因为stderr是关闭的，用户不知道，自然会抱怨'gc --auto'浪费CPU。

守护进程 gc 现在将 stderr 保存到 $GIT_DIR/gc.log。
在用户删除 gc.log 之前，以下 gc --auto 将不会运行并打印 gc.log。

Answer 6

这句话摘自；
使用 Git 进行版本控制

Git 自动运行垃圾收集：

• 如果存储库中有太多松散对象

• 当推送到远程存储库时

• 在执行一些可能会引入许多松散对象的命令之后

• 当某些命令（例如 git reflog 过期）明确请求时

最后，当您明确请求时，就会发生垃圾收集
使用 git gc 命令。 但那应该是什么时候呢？ 没有固体的
回答这个问题，但有一些好的建议和最好的
练习。

您应该考虑在少数情况下手动运行 git gc
情况：

• 如果您刚刚完成 git filter-branch 。 回想起那个
过滤器分支重写许多提交，引入新的，然后离开
裁判上的旧的应该在您满意后删除
与结果。 所有那些死去的物体（不再是
引用，因为您刚刚删除了指向它们的一个引用）
应通过垃圾收集删除。

• 在执行某些可能会引入许多松散对象的命令之后。 这
例如，可能需要进行大量的变基工作。

另一方面，
什么时候应该警惕垃圾收集？

• 如果存在您可能想要恢复的孤立引用

• 在 git rerere 上下文中，您不需要保存
永远的决心

• 在只有标签和分支就足以引起
Git 永久保留提交

• 在 FETCH_HEAD 检索的上下文中（通过 URL 直接检索
git fetch ），因为它们会立即受到垃圾收集

Answer 7

我在进行大量结帐后使用 git gc，并且有很多新对象。 它可以节省空间。 例如，如果您使用 git-svn 签出一个大型 SVN 项目，并执行 git gc，通常可以节省大量空间

Answer 8

您不必经常使用 git gc ，因为 git gc （垃圾收集）会在几个常用命令上自动运行：

git pull
git merge
git rebase
git commit

来源：git gc 最佳实践和常见问题解答

Answer 9

只是为了另一个观点，请注意，您可以拥有不想进行垃圾收集的存储库，自动或以其他方式（用作参考存储库，可能是本地克隆等），因为其他一些存储库使用此 git索引，如果对象消失或它们所在的文件具有不同的名称，则可能会变得无效。

在注重空间的 CI 场上，这可能是相当典型的情况，其中使用某些单个存储库作为基线（甚至可能通过 NFS 或类似的存储库）来为许多不同的测试/构建场景生成构建工作区。 您可以在存储库中使用 git config gc.auto false 来避免意外情况，并在您知道安全时才使用特定于域的脚本来执行 GC（例如，没有正在运行的构建 => 没有代理来执行 GC）。飞行途中腐败），甚至永远不会。

相反，您可能希望使用公共参考存储库，然后在实例化它们将构建的特定提交后分离工作区存储库（这仅复制所需的对象，可能会通过该工作区的浅度/深度设置来加速）以使它们独立，因此当不对主存储库进行 GC 至关重要时，减少时间窗口。

进行这种欺骗的一些原因包括：

• 使用与 SCM 平台链接速度较慢的 CI 场（例如，从公司 LAN 访问 GitHub 等），这样您只会遭受较长的 git 克隆 或类似的操作（并消耗上行链路流量，这在公司设置中可能成本高昂）每次构建一次，而不是针对每个场景；
• 确保您想要构建的提交在此构建期间可供所有代理使用（如果有人强制推送到 SCM 平台上的原始存储库/分支，就像在私人分叉的 PR 准备期间经常发生的那样，则可能会直接签出当构建代理准备好执行工作时是不可能的，因为 SCM 平台声称提交哈希不存在），或者对于命名分支构建 - 确保在同一构建的所有场景中使用相同的提示提交（并且是的，随着时间的推移，一些团队也会毫不犹豫地重新定义 git 标签）；
• 作为上述内容的延续 - 您的构建场景实际上可能会准备并归档 git 存储库的 tarball（垃圾收集的和所有），并将其作为临时工件分发给构建代理，以加快工作区实例化速度。 当代理不在同一构建主机甚至不在同一 LAN 上时，这种方法更有用。

来源/免责声明：制作 时吸取的经验教训https://github.com/networkupstools/jenkins-dynamatrix/blob/master/src/org/nut/dynamatrix/DynamatrixStash.groovy 和类似项目

Answer 10

当我进行大的提交时，尤其是当我从存储库中删除更多文件时，我使用......之后，提交速度更快

Answer 11

请注意，对存储库进行垃圾收集的缺点是，垃圾会被收集。 众所周知，作为计算机用户，我们现在认为是垃圾的文件可能在未来三天内变得非常有价值。 git 保留了大部分碎片，这一事实多次拯救了我——通过浏览所有悬空的提交，我恢复了许多我不小心保存的工作。

所以，在你的私人克隆中不要太爱整洁。 没有什么必要。

OTOH，对于主要用作遥控器的存储库，数据可恢复性的价值值得怀疑，例如。 所有开发人员推送和/或拉出的地方。 在那里，频繁地启动 GC 运行和重新打包可能是明智的。