Git LFSに格納されているタイプファイルのベストプラクティスはありますか？具体的には最小サイズですか？Git LFSは小さなファイルをうまく扱いますか？
たとえば、10MBの音楽ファイルが当てはまりますが、25kbのPNGはどうですか？ LFSに入れる価値があるのか、それともGitに処理させるほうが良いでしょうか？
LFSリポジトリにあまりにも多くの小さなファイルをチェックすると、パフォーマンスの低下が懸念されます。 LFS拡張が、より小さなバイナリファイルの束にどのように立ち上がるかに関するデータはありますか？特定のサイズのしきい値を超えてファイルを格納することをお勧めしますか？
私は正確な閾値が与えられるとは思わないでしょう。
LFSは、リモートリポジトリと同期するために交換する必要があるデータの量を節約します。ただし、大きなファイル自体が変更されていない限り、保存は適用されます。実際には変更されたファイルに対しては、LFSオブジェクトの変更を処理するために2つ目のrountripが必要になります。
したがって、ユースケースに変更がない（頻繁に）場合は、LFSでより小さなファイルを含めることができます。特定のブレークは、サーバーのI/O速度と、主にリポジトリとクライアント間の遅延とスループットにも依存します。
あなたの例では、PNGが決して変化しない場合の改善が期待されます。それぞれのコミットごとに（ほとんど）変更されるとすぐに、大きなファイルであってもLFSに置かれることで利益を得ることはできません。
また、2回目の往復の追加費用は、一般的なファイルが大きくなるほど重要ではなくなります。特に、ファイルクラス（サフィックス）のサイズが広い範囲で変化したり、ファイルクラス内の変更頻度が広いスペクトルをカバーしている場合は、質問に対する明確な答えが得られないことがあります。
私は、LFSのメリットとして、しばしばバイナリファイルの変更がレポサイズを膨らませないという印象を受けました。しかし、ファイルが頻繁に変更されると、実際には役に立たないと言っているように聞こえます。なぜそれを今まで使っているのですか？ – Chad
より正確であったはずです。オブジェクトblob（パックファイル）の意味でのレポサイズは小さくなります。私は、クライアントとサーバー間で転送されるデータの量を指していました。大抵の場合、ローカル業務が重要ではなく、変更には比較が必要となるため、大きなファイルのコスト面で重視しました。 LFSは、オブジェクトデータを処理する必要のある操作をすべて保存します。 – rpy
インデックス/メタデータのみが含まれている限り、違いはありません。 LFSでは、情報を保持するすべてのファイルの全サイズ（完全なリポジトリ）は小さくはありません（正直言ってもっと大きくても、すべてのバージョンを保存する必要があります）が、インデックス/メタデータを保存すると、 （ローカルまたはローカルインスタンスとリモーアインスタンスの間）。だから後の操作がスピードアップします。そして、これは主に、LFSの格納オブジェクトが変更されたオブジェクトではない場合に役立ちます。 – rpy
+1私もこの答えを知りたいと思います。たとえば、UE4には多くのバイナリUassetファイルがあります。多くは小さい（10-100KB）ものもあれば大きいもの（50MB +）です。 git-lfsがうまく動作すれば、 "* .asset"を追跡したいと思います。 – Chad