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

Question

我们是一个开发团队，他们在Windows文件共享上拥有我们的中央存储库。

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

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

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

Answer 1

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

Answer 2

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

也就是说，这种情况与“普通”本地存储库的情况没有什么不同，后者通常只由一个开发人员操作。

由于git-gc manual状态，Git确实通过运行git gc --auto对存储库执行某些检查，这可能会检测到GC是否需要并执行它。

因此...

1. git gc --auto将由运行在该存储库上的某个开发人员运行的Git进程自动生成。这将自己发生。

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

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

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

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

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

P.S。 您可能会发现this thread有趣的内容，尤其是讨论中提到的this post。

Answer 3

错误答案阅读评论。

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