一个“大文件”要从Git LFS中获益有多大？

Question

我正在阅读关于Git LFS的文章，并一次又一次地看到它对“大文件”很有用。

Git大型文件存储(LFS)取代大型文件，如音频示例、视频.

​

使用Git版本的大型文件--甚至那些大小可达几GB的文件。

​

Git大型文件存储(LFS)是一个免费的开源扩展，它用Git内的文本指针替换大型文件，并将这些文件的内容存储在远程服务器上。

不幸的是，我在任何地方都看不到“大文件”到底是什么。很明显，占用数千兆字节的东西是一个大文件，但是更小的文件呢？

我会从Git LFS中受益吗?它的“大文件”小到50 MB? 20 MB? 5MB? 1MB？不到1MB？

与普通Git相比，“大文件”必须从Git LFS中获益多少？

Answer 1

没有确切的阈值来定义什么是大文件。这取决于用户。要查看是否需要使用Git存储某些文件，需要了解git是如何工作的。

Git和其他源代码管理工具(perforce，svn)之间最根本的区别是，Git在每次提交时都存储存储库的完整快照。因此，当您有一个大文件时，快照包含此文件的压缩版本(如果文件未被更改，则包含指向该文件blob的指针)。存储库快照作为图形存储在.git文件夹下。因此，如果文件是“大的”，存储库的大小将迅速增长。

有多个条件来确定是否使用Git存储文件。

• 文件的大小。如果文件大于10 MB，则应考虑将其存储在Git LFS中。
• 文件被修改的频率。大文件(基于用户对大文件的直觉)经常更改的大文件应该使用Git LFS存储。
• 文件的类型。对于Git LFS存储，无法合并的非文本文件是可理解的。

我会从Git LFS中受益吗?它的“大文件”小到50 MB? 20 MB? 5MB? 1MB？不到1MB？

根据文件更改的频率，在提到的任何大小中，您都可以从中受益。考虑一下您每次执行100次提交编辑文件的情况。对于一个可以压缩的20 MB文件，比如15 MB，如果不使用Git存储该文件，存储库大小将增加大约1.5GB。

Answer 2

大多数版本控制系统都被优化为“小型的文本文件”。在任何VCS中存储一个100‘t的文件将占用至少100’t的文件系统(假设它不易被压缩)。如果您存储了3个完全不同的版本，那就是300 If的存储空间。

与分布式版本控制系统(如git )的不同之处在于，它们在每个工作副本中都包含完整的历史记录。这意味着每个文件的每个版本都占用了每个工作副本的空间，即使在以后的修订中删除了该文件，永远也是如此。(在集中式VCS上，这个空间只用于中央服务器。)

然而，有一个好的方面: git在存储事物的方式上相当聪明，在抽象的两个层次：

• 在某种程度上，git是一个“内容地址数据库”：它根据内容的散列来存储"blobs“。这意味着，只有当文件的内容发生变化时，才需要新的blob；实际上，只有在存储库的整个历史中从未发生过该内容时，才需要新的blob。
• 在下一级，即使是" blob“也可能不会全部存储在文件系统上，因为包装文件可能会将其作为一个类似blob的增量(一组更改)来包含。

这导致了一些考虑，即何时LFS或其他一些脱离回购的解决方案可能是有用的：

• 文件有多大？如果它是几兆字节，这可能就足以在历史上不包括它。
• 它多久变化一次？在每次提交时重新生成一个带有随机内容的100 10文件，每10次提交就会给每个工作副本增加一个10。
• 每个版本实际上都不同吗？如果您有两个不同版本的徽标，并不断改变您的想法使用，它将不会占用任何额外的空间，只要您使用完全相同的两个文件。同样的情况也适用于文件的重命名:如果内容不变，则不需要额外的"blob“。
• 从二进制的角度看，这些版本有什么不同？如果您一直附加到一个非常长的日志文件，git可能会注意到并将其存储在一个相对高效的包文件中。

Answer 3

LFS是维护项目资源的工具。假设您有一个项目，其中包含用于前端的*.psd文件。这些文件通常很大，文件的版本控制与以前的版本不一致(git保存提交中文本文件更改的历史记录，但对于二进制文件，则不能使用这种方法。两个diff文件的.cpp有意义，但两个原始图片的diff没有意义。)因此，如果您将资源存储在存储库中，那么其大小和克隆时间将是不光彩的增长。此外，维护将是困难的。

如何才能解决这个问题？首先，一个好主意是将大型文件的数据库从服务器端的代码中分离出来。另一种情况是，客户端允许将当前希望在其本地计算机上使用的部分文件(即，并不是所有以前的文件)提取出来。

LFS做什么？它散列其跟踪的文件，并将主题存储为指向原始文件的指针。将原始文件存储到服务器端的单独数据库中.本地存储库有其历史记录中的所有指针，但当签出特定提交时，它只会提取其内容。以这种方式，本地存储库的大小和克隆时间将显著减少。

PS:在lfs中接收文件的方法不同于git。因此，我认为它使用一些技术来分割大文件，将它们发送到不同的并行连接中，并将它们合并.这些东西可以改善它的功能..。但是重要的是，它可以增加数百/数千个小文件的克隆/拉时间。

还请注意，git与windows中的4GB较大的文件有问题。