我正在阅读有关Git LFS的内容，并一次又一次地看到它对“大文件”很有用
Git大文件存储（LFS）取代了大型文件，如音频样本，视频[...]
版本大文件 - 即使是那些大到几GB的大文件 - 使用Git。
Git大文件存储（LFS）是一个免费的开源扩展，它用Git中的文本指针替换大文件，并将这些文件的内容存储在远程服务器上。
不幸的是，我没有看到任何“大文件”实际上是什么。很明显，占用几千兆字节的东西是一个大文件，但更小的东西呢？
我将从Git LFS中获益，只需50 MB的“大文件”吗？ 20MB？ 5MB？ 1MB？不到1MB？
与常规Git相比，“大文件”必须从Git LFS中受益多大？
没有确切的阈值来定义什么是大文件。这取决于用户。要查看是否需要使用Git LFS存储一些文件，您需要了解git的工作原理。
Git和其他源代码控制工具（perforce，svn）之间最根本的区别在于Git在每次提交时都存储了存储库的完整快照。因此，当您有一个大文件时，快照包含此文件的压缩版本（如果文件未更改，则指向文件blob的指针）。存储库快照存储为.git文件夹下的图形。因此，如果文件“大”，则存储库大小将快速增长。
有多个标准可确定是否使用Git LFS存储文件。
我将从Git LFS中获益，只需50 MB的“大文件”吗？ 20MB？ 5MB？ 1MB？不到1MB？
根据文件更改的频率，提及的任何大小都可以使您受益。考虑每次执行100次提交编辑文件的情况。对于可以压缩的20MB文件（例如15 MB），如果文件未使用Git LFS存储，则存储库大小将增加大约1.5GB。
LFS是一种维护项目资源的工具。假设您有一个项目，其中包含前端使用的*.psd文件。这些文件通常很大，文件的版本控制不符合以前的版本（git保存了提交中文本文件的更改历史记录，但是对于二进制文件，这种方法无法使用。两个diff文件的.cpp有意义，但diff为2原始照片没有。）因此，如果您将资源放入存储库，其大小和克隆时间将变得难看。而且维护很难。
怎么能克服这个问题？首先，一个好主意是从服务器端的代码中拆分大文件的数据库。另一个是客户端允许他们想要在他/她的本地机器上使用他们想要使用的部分（即不是所有以前的文件）。
LFS做什么？它将其跟踪的文件和存储主题作为指向原始文件的指针。将原始文件存储到服务器端的单独数据库。本地存储库在其历史记录中包含所有指针，但是当您签出特定提交时，它只会提取其内容。以这种方式，本地存储库的大小和克隆时间将显着减少。
PS：在lfs中接收文件的方法与git不同。所以我认为它使用一些技术来分割大文件，将它们发送到不同的并行连接并合并它们......以及可以改善其功能的东西......但重要的是它可以增加克隆/拉动的时间对于数百/数千个小文件。
另请注意，git在Windows中的4GB文件有问题。