我有一种情况，可以用下面的SO注释优雅而准确地表达：
我的比特桶回购中的存储空间实际上已经用完了我最初关心太空的原因。我的理解一般git的原则是git有一个垃圾收集器定期运行并删除任何没有不再引用它。LFS文件肯定没有提交引用它，所以根据git原则，这些文件应该自动删除，对吧？
那么，不再在本地存储库中的旧的、过时的LFS文件的空间最终会被Git GC占用吗？这意味着，如果我等待足够长的时间，我将不再"存储空间不足"；因为GC释放了空间？
如果有关系的话，我的主人是比特桶。
由于LFS存储主机的共享性质，存储主机永远无法知道何时可以安全地删除文件。因此，您必须手动告知存储主机要删除哪些文件。
通常，git可以安全地删除它不再引用的文件，因为repo是自包含的，具有切换到任何给定分支或提交所需的一切。如果git无法再访问该提交，那么就不可能只需要该提交引用的文件。这就是git能够安全地删除文件的原因。如果文件被另一个repo中的提交引用，则该repo必须具有该文件的副本，无论何时将提交推送到远程，都可以推送该副本。通过使用LFS，回购不再是自包含的。一些文件现在存储在LFS存储主机中，而不是存储在repo本身中。相反，这些文件作为引用存储在repo中，并根据需要从存储主机提取(使用缓存，以便不需要每次从存储主机提取文件(。
git是一种分布式SCM。这使得很难/不可能知道存在的回购的所有各种克隆。因此，LFS的存储主机永远不可能知道repo的所有克隆上存在的所有提交，因此也不可能知道何时可以安全地删除文件。LFS所能做的最好的事情就是从您的本地机器中删除LFS文件的本地副本。
您可以提供一套合理删除的规则。例如，如果自原始存储库中的任何提交上次引用该文件以来，该文件已至少一个月，则该文件将被修剪。但是，您最终可能会发现本地存储库挂起了对存储主机上不再存在的文件的引用。但是，如果要从存储主机中删除文件，就必须冒这个风险。
以下是一个有点做作的示例，但它说明了为什么很难知道何时可以安全地从LFS存储主机中删除文件。让我们说有人休育儿假。在他们的本地回购中，是一个已经在原始回购中删除的分支。一个月过去了，存储主机上的文件将被修剪，因为它在原始回购中没有被引用。该人员返回并决定签出给定的分支(可能是第一次(。他们的本地repo没有LFS引用引用的文件的副本。它向存储主机请求该文件的副本，然后发现该文件已不存在。没有什么可以做的，这个分支/承诺现在永远被打破了。
从git LFS v2.4，您可以使用git lfs ls-files --all列出从当前存储库可访问的所有LFS文件。也就是说，所有文件都可以从所有可访问的提交中访问，而不仅仅是从一个给定的提交中。这将有助于确定哪些文件可以安全删除。
似乎必须手动删除它们
Git LFS命令行客户端不支持从服务器修剪文件，因此如何删除文件取决于您的托管提供商。
在Bitbucket Cloud中，您可以通过Repository Settings查看和删除Git LFS文件>Git LFS: