Git LFS 中存储的类型文件是否有最佳实践？专门针对最小尺寸？
例如，一个 10mb 的音乐文件显然很合适，但是 25kb 的 png 呢？是否值得放入 LFS 或让 Git 处理它更好？
我担心的是将太多小文件检入 LFS 存储库时性能会下降。 是否有关于 LFS 扩展如何经得起一堆较小的二进制文件的任何数据？只存储超过特定大小阈值的文件是否可取？
最佳答案
我不希望给出一个确切的阈值。
LFS 节省了为与远程存储库同步而需要交换的数据量。但是，保存仅适用于大文件本身没有更改的情况。实际上，对于更改的文件，您需要第二次往返来处理 LFS 对象上的更改。
因此，如果在您的用例中这些文件没有(经常)更改，您可以将较小的文件包含在 LFS 中。具体的收支平衡将取决于服务器的 I/O 速度，主要取决于存储库和客户端之间的延迟和吞吐量。
在您的示例中，我仍然希望在 png 几乎永远不会改变的情况下有所改进。一旦它们要在每次提交时(几乎)发生变化，即使更大的文件也可能无法从放入 LFS 中获益。
此外，典型文件越大，第二次往返的额外成本将变得越来越不重要。特别是当文件类(后缀)的大小在很大范围内变化和/或文件类内的更改频率涵盖很广的范围时，您的问题可能没有明确的答案。
关于git - Git LFS 处理小文件的能力如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35787080/