我有一个git存储库来跟踪我在uni的课程。 .pdf中的一些讲座幻灯片有时会很大（20-30MB），这使我想知道什么时候通常的不要在git中放大文件！？
我以我的情况为例，但确实对文件大小/更改频率的一般限制感兴趣，这是应该考虑的。
在该存储库中，我为所修的每门课程都有一个目录，每个目录均包含作业和项目的代码。我还希望将每个课程的幻灯片放在那里，以便于同步。
据我所知，GitHub阻止的文件大于1GB。但是，我正在使用的git repo托管在我与朋友共享的1 TB专用计算机上，所以我想还适用其他限制吗？
通常，我永远不会将大于100MB的数据库添加到git中，但是该规则是否适用于20-50MB的文件（讲座幻灯片），这些文件永远也不会更改一次？
答案 0 :(得分：1)
让我们暂时假设您想将所有这些文件保存在一棵树中 ，无论出于何种原因，您都想使用git来管理它们（因为这对您来说更简单，在您的环境中无处不在等等。
人们谈论大文件时的典型建议是将它们指向Git大文件存储（LFS）。 Git LFS的工作原理是让您指定这些大文件，它将从存储库本身中删除它们并将它们放置在单独的LFS存储位置。克隆存储库时，您将获得有关文件的元数据，以及足够的信息，以使您在签出分支机构时git-lfs可以从LFS存储区下载这些大文件并将其放在磁盘上。
这很有用，因为您不需要获取所有数据，大型文件的多个旧版本或其他分支中的大型文件的所有。您只下载需要检出HEAD的文件。
让我们在一些方面将Git LFS与“纯” git进行比较：
下载
在您的方案中，您没有修改这些文件。您只有一个修订，并且总是希望将其签出。因此，git-lfs和常规git使用的大约带宽和时间是...相同。
（这是假设这些文件不能很好地压缩或共享很多，这是一个很好的猜测。但是，如果这是一个糟糕的猜测，那么git最终可能会比基于Git LFS发送数据的方式。）
磁盘上存储
无论使用哪种解决方案，显然您都将需要足够的磁盘空间来将文件的检出版本存储在工作目录中。但是，对于常规git，您还需要将副本作为git“对象”存储在git存储库中。
这表明git作为分布式版本控制系统而存在，当您克隆存储库时，您将复制存储库中存在的每个文件的每个版本的副本。
因此，如果签入10 GB的文件，则需要20 GB：10 GB的文件将其存储在可以访问该文件的工作目录中，另外10 GB的文件作为对象存储在目录中。 Git存储库。 （再次假设内容压缩不正确。）
托管
如您所述，某些托管服务提供商对存储库的大小进行了限制。由于是将其托管在自己的服务器上，因此只需要确保有足够的磁盘空间和带宽即可克隆。
因此在您的方案中，只要您有足够的磁盘空间来容纳当前工作目录内容的两倍大小，那么git（不使用Git LFS）是一个不错的选择。