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