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如何處理小文件？

回答

相關問題