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

Question

摘要

我有一个 git 存储库来跟踪我在大学的类(class)。 .pdf 格式的一些讲座幻灯片有时相当大(20-30MB)，这让我想知道不要将大文件放入 git! 的通常智慧何时开始适用？

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

示例案例

在该存储库中，我为我正在学习的每门类(class)都有一个目录，每个目录都包含作业和项目的代码。我还希望将每门类(class)的幻灯片放在那里，以便于同步。

据我所知，GitHub 会阻止超过 1GB 的文件。但是，我正在使用的 git 存储库托管在我与 friend 共享的私有(private) 1 TB 计算机上，所以我猜还有其他限制？

一般来说，我永远不会向 git 添加 >100MB 的数据库，但是此规则是否适用于永远不会(也许一次)更改的 20-50MB 文件(讲座幻灯片)？

Answer 1

让我们假设您希望将所有这些文件保存在一棵树中并且无论出于何种原因您都希望使用 git 来管理它们(因为这对您来说更简单，工具是在您的环境中无处不在，等等)。

当人们谈论大文件时，典型的建议是将其指向 Git 大文件存储 (LFS)。 Git LFS 的工作原理是让您指定这些大文件，它会将它们从存储库本身中删除，并将它们放入单独的 LFS 存储位置。当您克隆存储库时，您将获得有关文件的元数据，这些信息足以让您在 checkout 分支时，git-lfs 可以从 LFS 存储区域下载这些大文件并将它们放在磁盘上。

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

让我们在几个方面将 Git LFS 与“纯”git 进行比较:

下载

在您的场景中，您不会修改这些文件。您只有一个修订版，并且您希望始终对其进行检查。因此 git-lfs 和常规 git 使用的大致带宽和时间是......相同的。

(这假设这些文件压缩得不好，或者共享很多共同点，这是一个很好的猜测。但如果这是一个糟糕的猜测，那么 git 最终可能会比Git LFS 基于其发送数据的方式。)

磁盘存储

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

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

因此，如果 checkin 10 GB 文件，则需要 20 GB:10 GB 将其存储在可以访问该文件的工作目录中，另外 10 GB 将其作为对象存储在Git 存储库。 (这再次假设内容压缩得不好。)

托管

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

因此，在您的场景中，只要您有足够的磁盘空间来容纳当前工作目录内容大小的两倍，那么 git(不带 Git LFS)就是一个绝佳的选择。