ベストアンサー1
これらは、この主題に関して私が考えたことです。最終的には、アセットとコードを可能な限り分離しておく必要があるかもしれません。考えられる戦略はいくつかあります。
分散型、2つのリポジトリ
アセットは 1 つのリポジトリに、コードは別のリポジトリにあります。
利点
- Web 開発のコンテキストでは、グラフィック ファイルを直接操作していない場合は、巨大なアセット リポジトリをクローンする必要はありません。これは、動的コンテンツ (PHP、ASP.NET、RoR など) とは別にアセットを処理し、アセット リポジトリと同期している Web サーバーがある場合に可能です。
デメリット
DVCSツールは自身のリポジトリ以外のリポジトリを追跡しないため、直接的なBOM（部品表）サポートはありません。つまり、両方のリポジトリが同期しているかどうかを明確に判断する方法はありません。（これがgit サブモジュールまたはレポのためです。
例：アーティストが 1 つのリポジトリに新しい画像を追加し、プログラマーがその画像を使用するための機能を追加しますが、誰かがバージョンをさかのぼる必要がある場合、何らかの方法でこれらの変更を自分で追跡する必要があります。
アセット リポジトリのオーバーヘッドは、それを使用するユーザーにのみ影響します。
分散型、1つのリポジトリ
アセットとコードは同じリポジトリに存在しますが、2 つの別々のディレクトリにあります。
利点
- コードとアセットのバージョン管理が相互に絡み合っているため、BOM が実用的です。バックトラックも問題なく実行できます。
デメリット
- 分散バージョン管理ツールはプロジェクト全体の構造を追跡するため、通常、1 つのディレクトリだけをチェックアウトする方法はありません。
- リポジトリのオーバーヘッドの問題はまだ残っています。さらに、コードだけでなくアセットもチェックアウトする必要があります。
上記の両方の戦略には、大規模なアセット リポジトリをクローンする必要があるため、依然としてオーバーヘッドが大きいという欠点があります。この問題の解決策の 1 つは、上記の最初の戦略のバリエーションである 2 つのリポジトリです。コードを分散 VCS リポジトリに保持し、アセットを集中 VCS リポジトリ (SVN、Alienbrain など) に保持します。
ほとんどのグラフィック デザイナーがバイナリ ファイルで作業する方法を考慮すると、本当に必要な場合 (ずっと後になってから必要になる大量のアセットを必要とする新機能など) を除いて、通常は分岐する必要はありません。欠点は、中央リポジトリをバックアップする方法を見つける必要があることです。したがって、3 番目の戦略があります。
オフリポジトリアセット（またはCMS内のアセット）
コードは通常どおりリポジトリにありますが、アセットはリポジトリにありません。アセットは、代わりに何らかのコンテンツ/メディア/アセット管理システムに配置するか、少なくとも定期的にバックアップされるフォルダーに配置する必要があります。これは、グラフィックを含むバージョンをバックトラックする必要がほとんどないことを前提としています。バックトラックが必要な場合は、グラフィックの変更はごくわずかです。
利点
- コード リポジトリを肥大化させません (頻繁にファイル チェックを行う git などに役立ちます)
- 資産専用のサーバーに資産を配置するなど、資産の柔軟な取り扱いが可能
- APIを備えたCMSの場合、アセットはコード内で比較的簡単に処理できるはずです。
デメリット
- BOMサポートなし
- 簡単に広範囲のバージョンバックトラッキングをサポートしていないため、これは資産のバックアップ戦略に依存します。