"場合によります。" 通常の開発追跡では、ありません。ただし、クラウドおよびDevOpsの導入では、多くの場合、便利であり、必要な場合さえあります。
ほとんどの場合、
@ ptyxが正しいです。確かに、彼の「いいえ」はもう少し強調して述べることができます。「No. No！OMG NO！」のようなもの
縮小または圧縮されたアセットをGitのようなソース管理システムに保存しないのはなぜですか？
それらは、ソースコードからオンザフライでビルドプロセスによってほぼ簡単に再生成できます。圧縮されたアセットを保存することは、基本的に同じ論理コンテンツを2回保存することです。これは、「自分を繰り返さないでください」（別名DRY）の原則に違反しています。
哲学的ではありませんが、より実用的な理由は、Gitに保存すると、圧縮/圧縮されたアセットの圧縮率が非常に低くなることです。ソース管理システムは、保存されている各ファイルの異なるバージョン間の変更（「デルタ」）を認識することによって機能します。これを行うには、最新のファイルを以前のバージョンと「差分」し、これらの差分を使用して、ファイルのすべてのバージョンの完全なコピーを保存しないようにします。しかし、minify / optimizeステップで行われた変換は、diff / deltaアルゴリズムが使用する類似点とウェイポイントをしばしば削除します。最も簡単な例は、改行やその他の空白を削除することです。結果として生じる資産は、多くの場合、1つの長い行にすぎません。ウェブビルドプロセスの多くの部分-のようなツールバベル、UglifyJS、Browserify、LessとSass / SCSS-アセットを積極的に変換します。それらの出力は不安定です。入力がわずかに変化すると、出力に大きな変化が生じる可能性があります。その結果、diffアルゴリズムは、毎回ほぼ完全に異なるファイルを参照すると信じることがよくあります。その結果、リポジトリはより速く成長します。ディスクは十分な大きさであり、ネットワークは十分に高速である可能性があります。特に、縮小/最適化されたアセットを2回保存する価値がある場合は、ポイント1に基づいて、余分なコピーは100％無意味である可能性があります。膨満。
ただし、これには大きな例外があります。DevOps /クラウドデプロイメントです。多くのクラウドベンダーとDevOpsチームは、Gitなどを使用して、開発の更新を追跡するだけでなく、アプリケーションとアセットをテストサーバーと運用サーバーに積極的に展開しています。この役割では、Gitが「変更されたファイル」を効率的に判断する機能。「各ファイル内で何が変更されたか」を判断するためのより詳細な機能と同じくらい重要です。Gitが縮小/最適化されたアセットのほぼ完全なファイルコピーを実行する必要がある場合、それ以外の場合よりも少し時間がかかりますが、それぞれの「プロジェクト内のすべてのファイル」のコピーを回避するのに役立つ優れた作業を行っているため、大したことはありません。展開サイクル。
デプロイエンジンとしてGitを使用している場合、縮小/最適化されたアセットをGitに保存すると、「いいえ」から切り替わることがあります。望ましい。実際に、デプロイするサーバー/サービスでの堅牢なビルド/後処理の機会がない場合などに必要になることがあります。（その場合の開発資産と配備資産を分割する方法は、別のワームの缶です。現時点では、単一の統合リポジトリ、複数のブランチ、サブリポジトリ、または複数の重複するリポジトリなど、いくつかの方法で管理できることを知っていれば十分です。 ）
/dev/null。