ウェブサイトのバージョン管理：dev / productionフロントエンドファイル
私は私たちのウェブサイトプロジェクトをバージョン管理するためのより良い方法を考えています。私はフロントエンドの開発者にすぎないため、VCSについての深い知識はありません。
ワークフローは変化しており、過去のバージョン管理の習慣は時代遅れになっています。主な問題は、各Webサイトにフロントエンドファイルの2つの配列があることです。
開発環境（少ないファイル、非圧縮のjs、イメージなど）。ビルド環境、「不正」（すべてが圧縮され、人間が読み取れない）。
ただし、ソースファイルを含むWebサイトを販売することはできません。まあ、それは完全に正しくないと感じています。
2つのリポジトリを持つソリューションがあります。1つはビルド、1つは開発で、gulpがdevファイルをビルドディレクトリに送信します。しかし、それを維持するのは面倒であり、小さな会社では、それはそれほど素晴らしいとは思いません。それは多くのレポジトリを作成し、人々はいくつかのレポジトリで管理しなければならず、時には1つのsvnレポでも問題が発生します。
したがって、同じsvn内のソースファイルとprodファイルの1つのリポジトリを持つソリューションもあります。ただし、Webサイトがローカルの開発サーバーから本番サーバーに移動するときに、ソースファイルを削除する必要があります（そのため、単一のリポジトリには、場所、開発、または本番に基づいて異なるファイルがあります）。聞いたところ、良くない
バージョン管理システムに関して、不適切なフロントエンドワークフローを管理する正しい方法は何ですか？
ソース管理の基本的なルールの1つは、手動で作成したartifactsをリポジトリ（元のソースファイル）に入れるだけでよく、「コンパイル」または「生成」できるすべてのものを保存する必要がないことです。冗長性を生み出すからです。 1つcan（オプション）ビルドプロセスの中間出力/部分をリポジトリ（アーティファクトとも呼ばれる）に保存します。これらを再現する手順が完全に自動化されていない場合、またはビルド時にキャッシュの目的で出力を再現する手順は遅いです。
したがって、devソースファイルから本番ファイルを生成する完全に自動化されたプロセスがある場合、（本番ファイルを作成するためのスクリプトと共に）devファイルをソース管理に置くだけで済みます。そうでない場合は、そのようなプロセスを確立します。ソースから生成された後、手動で本番ファイルをいじる必要がないことを確認してください。 VCSから「直接」デプロイする場合は、devソースファイルをソース管理から引き出し、「誤解」を引き起こし、結果のファイルを1つのステップで本番環境に転送するデプロイスクリプトがあることを確認してください。
もちろん、ソース管理を「貧弱なバックアップ」または本番ファイルのキャッシュとしても使用したい場合は、この目的のために2番目のリポジトリを設定し、生成後に本番ファイル構造のコピーを置くことができます。このリポジトリは開発に役立ちません。また、設定した後は、手動でメンテナンスする必要はありません。したがって、必ずこの「製品リポジトリ」にバックアップを作成するための手動の手順はありません-自動的にバックアップを作成するデプロイスクリプトに必要な手順を含めます。展開後の運用環境への手動変更を禁止できない場合は、別のバックアップスクリプトを追加することを検討してください。このようにして、リソースが限られている場合でも、プロセスを保守可能な状態に保つことができます。
そして、はい、これは厳密に分離された2番目のリポジトリである必要があります。これは、開発リポジトリとは完全に異なる目的と異なるライフサイクルを持っているためです。これはバックアップにのみ使用し、別のプロセスであるソース管理には使用しません。