Git LFS如何处理小文件？

存储在Git LFS中的类型文件是否有最佳做法？特别是对于最小尺寸？Git LFS如何处理小文件？

例如，一个10MB的音乐文件显然是合适的，但25kb的png呢？值得投入LFS还是让Git处理它更好？

我的问题是检查过多的小文件到LFS回购时性能下降。 有没有关于LFS扩展如何代表一堆较小的二进制文件的数据？建议只存储超过特定大小阈值的文件吗？

来源

2016-03-04 James McMahon

+1我也想知道这个答案，例如UE4有许多二进制uasset文件。许多很小（10-100KB），有些很大（50MB +）。我想只跟踪“* .uasset”，如果git-lfs运行良好。 – Chad

我不希望给出一个确切的阈值。

LFS节省了需要交换的数据量，以便与远程存储库同步。但是，只有在大文件本身没有变化的情况下，保存才适用。实际上，对于更改后的文件，您需要第二个rountrip来处理LFS对象上的更改。

因此，如果在使用情况下不会更改（频繁），则可以使用LFS包含较小的文件。具体的收支平衡将取决于服务器的I/O速度，主要取决于存储库和客户端之间的延迟和吞吐量。

在你的例子中，我仍然期待pngs接近永不改变的情况下的改进。一旦他们要改变（几乎）每一次提交，甚至更大的文件可能不会因为被放入LFS而受益。

此外，第二次往返的额外成本将越来越不重要的典型文件越大。尤其是当文件类（后缀）的大小在很大范围内变化和/或文件类中的变化频率覆盖范围广时，您的问题可能没有明确的答案。

来源

2016-04-03 18:44:08 rpy

我的印象是，LFS的好处是经常变化的二进制文件不会扩大回购大小。但听起来好像你在说，当文件经常变化时它实际上没有帮助;那为什么要用它呢？ – Chad

应该更精确。对象blob（包文件）意义上的Repo大小更小。我指的是需要在客户端和服务器之间传输的数据量（推拉操作）。由于本地操作通常并不重要，而且无论如何都需要进行比较，所以我专注于大型文件的主要成本方面。 LFS将保存任何需要处理对象数据的操作。 – rpy

只要涉及到索引/元数据，您就不会有差异。有了LFS，保存信息的所有文件（完整存储库）的总体大小不会更小（说实话，即使更大，仍然需要存储所有版本），但是保存索引/元数据将加速所有对象更改的确定（本地或本地和再次实例之间）。所以后来的操作会加快。这将大多受益于LFS存储对象不是已更改的情况。 – rpy

Git LFS如何处理小文件？

回答

相关问题