git - 文件共享上的 git 是否需要显式 git gc？

Question

我们是一个开发团队，我们的中央存储库位于 Windows 文件共享上。

我们的一位开发人员错误地在一个分支上推送了大量的提交。之后，我们从中央存储库中删除了该分支，但显然这并没有真正删除提交。

由于它只是一个文件共享，因此文件服务器上没有自动运行的进程git gc。

我们是否需要git gc在中央存储库上显式运行？

Answer 1

您的本地存储库也没有进程。
git gc不是由后台服务运行的。它由客户端在某些命令后自动运行，例如commit当push达到应删除的对象的某个阈值时。

Answer 2

正如 Daniel 所说，存储库位于共享文件系统上的事实对 Git 来说并没有什么特别之处：就像这个存储库位于常规文件系统上一样。因此没有服务器，只有一堆“客户端”Git 进程访问同一个存储库。

也就是说，这种情况与通常仅由单个开发人员操作的“普通”本地存储库的情况并没有真正的不同。

正如git-gc手册所述， Git 确实通过运行对存储库执行某些检查，git gc --auto这可能会检测到需要 GC 并执行它。

所以...

1. git gc --auto将由您的一位开发人员在该存储库上运行的 Git 进程自动生成。这一切都会自行发生。

   文档中未明确指定可能触发此操作的精确 Git 操作。我认为这是因为对此进行编码是没有意义的（无论如何，这种 GC 应该是快速和透明的）。

2. 我认为你没有理由不用手跑来git gc --aggressive回收可用空间。

   你必须记住，如果你启用了 reflog，你可能想要

   • 确保清空 reflog（通过git reflog expire --all或更细粒度的方法，例如仅手动删除所需的条目）。
   • 没有其他挥之不去的引用（分支或标签）指向那个不需要的历史。

   另请注意，虽然 Git 应该正确序列化对存储库的所有访问并在操作对象时使用“创建 + 原子重命名”操作，但我会要求开发人员在对其执行垃圾收集时不要访问存储库。

PS 你可能会觉得这个帖子读起来很有趣，尤其是讨论中提到的这篇文章。

Answer 3

错误答案阅读评论。

git gc删除已暂存的无法访问的对象（使用git add.）。我认为它永远不会删除已提交的文件。