什么时候单个文件对于git来说太大？ 总结

我有一个git存储库来跟踪我在大学的课程。pdf中的一些演讲幻灯片有时相当大（20-30MB），这让我想知道通常的智慧是什么时候不会将大文件放在git中！开始申请

我以我的情况为例，但我真正感兴趣的是应该考虑的文件大小/更改频率的一般限制

例 在这个存储库中，我有一个我正在学习的每门课程的目录，每个目录都包含作业和项目的代码。我还想把每门课程的幻灯片放在那里，以便同步

据我所知，GitHub阻止大于1GB的文件。但是，我使用的git repo托管在我与朋友共享的一台私人1 TB机器上，所以我猜还有其他限制吗

---

一般来说，我不会将大于100MB的数据库添加到git中，但这条规则是否适用于20-50MB的文件（课堂幻灯片），这些文件可能永远不会改变，也许一次也不会改变？

让我们假设一下，您希望将所有这些文件保存在一个树中，并且出于任何原因，您希望使用git来管理它们（因为它对您来说更简单，所以这些工具在您的环境中无处不在，等等）

当人们谈论大文件时，典型的建议是将他们指向Git大文件存储（LFS）.Git LFS的工作原理是允许您指定这些大文件，它将从存储库中删除这些文件，并将它们放在单独的LFS存储位置。克隆存储库时，您将获得有关文件的元数据，以及足够的信息，以便在签出分支时，Git LFS可以从LFS存储区域a下载这些大文件然后把它们放到磁盘上

这很有帮助，因为您不需要获取所有数据、多个旧版本的大型文件或其他分支中的大型文件。您只需下载您需要的内容即可签出

HEAD

让我们在以下几个方面将Git LFS与“纯”Git进行比较：

下载

在您的场景中，您没有修改这些文件。您只有一个版本，并且希望始终签出它。因此git lfs和常规git使用的带宽和时间大致相同

（这假设这些文件没有很好地压缩，或者共享了很多相同的文件，这是一个很好的猜测。但是如果这是一个很差的猜测，那么git可能最终会比git LFS更高效，这取决于它发送数据的方式。）

磁盘存储

无论使用哪种解决方案，显然您都需要足够的磁盘空间将文件的签出版本存储在工作目录中。但是，使用常规git，您还需要将副本作为git“对象”存储在git存储库中

这表明git是一个分布式版本控制系统，当您克隆存储库时，您将获得存储库中存在的每个文件的每个版本的副本

因此，如果签入一个10GB的文件，则需要20GB:10GB将其存储在可访问的工作目录中，另外10GB将其作为对象存储在Git存储库中（这同样假设内容压缩不好）

托管

正如您所指出的，一些托管提供商对存储库的大小进行了限制。由于您在自己的服务器上托管存储库，您只需确保您有足够的磁盘空间和带宽进行克隆

---

因此，在您的场景中，只要您有足够的磁盘空间容纳当前工作目录内容的两倍大小，那么git（没有git LFS）是一个很好的选择。

“什么时候认为单个文件对于git来说太大？”当您发现它会导致无法接受的存储成本或性能下降时。Git不会在某个时候停止工作，它只会花费更长的时间。计算存储库大小、带宽等非常简单。当10GB文件更改1位时，您现在需要30GB，不是吗？没有lfs的Git似乎不适用能够处理这么大的文件。确切地说，这就是LFS存在的原因。