0

ファイルを3つのカテゴリに分類できる複雑なWebプロジェクトテンプレートがあります。まず、各サーバーで一意である必要がある設定関連ファイルは頻繁に更新されませんが、バージョン管理に含めると便利です。次に、開発者によってコーディングされた実際のファイルであり、プロジェクトごとに一意であり、バージョン管理されるメインファイルである開発ファイル。そして最後に、ユーザーが生成したコンテンツは、ほとんどがステージおよび開発環境のテストデータですが、ライブサーバーの適切なデータであり、理想的にはバージョン管理も行う必要があります。

すべてのプロジェクトのルートフォルダーには、最初のグループの一部である設定ファイルがあり、次に開発ファイルを含む3つのフォルダーがあり、最後にWebサイトの画像とユーザー生成ファイルを含むフォルダーがあります。

私が試したこと:

ローカルライブとステージで同じユーザー生成コンテンツがあり、ローカルからステージへ、ステージからライブへプッシュするたびに設定ファイルを再調整する必要があるため、フォルダー全体を使用することはできません。

開発ファイルにはマスターブランチを使用し、ユーザー生成コンテンツと設定ファイルには別のブランチを使用して、マスターをローカルからステージなどにプッシュしてみました。しかし、ステージでチェックアウトを行うと、無関係なファイル。

開発、ユーザー生成コンテンツ、設定用に別々のブランチを作成してみました。ステージにプッシュした後、すべてをマスターにマージしました。この場合の問題は、コミットプロセスが少し複雑になるローカル開発サーバーで発生します。checkoutdev; 変更されたファイルを追加します。devをコミットします。チェックアウトマスター; devugc設定をマージします。この場合、ugcで追跡されたファイルの一部が失われることも心配です。

大きな問題

誰かが新しいソリューションや、それらを可能にするために現在のソリューションに追加する何かを提案できますか?残念ながら、使用するフレームワーク(プライベートフォルダー)では許可されていないため、個別のフォルダーを使用することはできません。

4

1 に答える 1

0

これは本当にひどい整理方法ですが.gitignore、特定のリポジトリに属していないものをすべて無視するファイルでネストされたGitリポジトリを使用できます。

.git/
.gitignore   <---- ignoring everything except settings-file
your_project
  .git/
  .gitignore <---- ignoring settings-file, user content, and user-content/.git
  dev-folder-1/
  dev-folder-2/
  settings-file
  user-content/
    .git/
    .gitignore <-- ignoring everything except user content

これにより、ファイル構造のさまざまな部分を追跡する3つの異なる「重複する」リポジトリを効果的に作成できます。

しかし、実際には、ファイルやバージョン管理のニーズを再編成する方法を見つける方がよいでしょう。

于 2011-01-10T08:54:00.817 に答える