25

GITを使用してコンテンツ管理システム（CMS）プロジェクトを管理しています。CMSは複数のプラグイン（モジュール）を持つことができます。

つまり、基本的に、3種類のリポジトリが必要です。

  • コアCMS開発（すべての新しいプロジェクトは、その最後の安定した未構成バージョンのチェックアウトです）
  • モジュール/プラグインごとに1つのリポジトリ。（すべての新しいプロジェクトは、実装したいモジュールの最後の安定バージョンをチェックアウトします）
  • プロジェクトごとに1つのリポジトリ（各クライアントは、コアCMSおよびモジュールからのパーソナライズを表すリポジトリになります）

タイプ1と2の場合、これは単純な基本リポジトリだと思います。しかし、クライアントプロジェクトになると、私は混乱します。

  • 最初にCMSのクローンを作成し、次に/ modules /フォルダーに移動して、必要なすべてのモジュールを再度クローンしますか？これにより、リポジトリ内にリポジトリが作成されます。最初のリポジトリは、各モジュールの.git /フォルダーをログに記録しようとしますか？
  • 各クライアントはモジュールをパーソナライズする必要があるため、サブモジュールを使用できません。
  • モジュールのコアコンポーネントを変更した場合（パーソナライズではなく、バグ修正のみ）、その単一のファイルを元のモジュールリポジトリにプッシュできますか？
  • （全体に広がるモジュールunitTestについては話していません）

したがって、問題は次のとおりです。効率的にするには、リポジトリ/ファイル/フォルダをどのように整理する必要がありますか？

4

2 に答える 2

13

あなたが説明したレイアウトは、gitサブモジュールで本当にうまく機能します。ドキュメントを読んで、いくつかのチュートリアルを試すことをお勧めします。計画で導入される主な違いは、各クライアントリポジトリとクライアントプラグインリポジトリに1つではなく2つのリモートがあることです。そして、あなたが新しいクライアントプロジェクトを始めたいとき、あなたはする必要があるでしょう

  1. メインラインのcmsをフォークする
  2. 変更されるすべてのプラグインをフォークします
  3. （1）からフォークされたcmsのクローンを作成し、そのサブモジュールを更新して（2）からの新しいリモートを指すようにします。
  4. サブモジュールの初期化/更新
  5. （オプション）メインラインのcmsURLをクライアントのフォークされたcmsにリモートとして追加します
  6. （オプション）メインラインプラグインのURLをクライアントのフォークされたプラグインのリモートとして追加します

より良いオプションは、同じリポジトリを使用して、クライアントごとにブランチを作成することです。それが私がそれをする方法です。

于 2011-03-25T20:08:15.257 に答える
8

短い更新/前の回答に関する追加情報：アプローチが気に入らない場合、git submodulesまたはこれを理解するのが難しすぎると思われる場合は、試してみてください

サブモジュールの代わりに別の依存関係マネージャー（Rubyの場合はRubyGems、PHPの場合はComposerなど）を使用できるかどうかを確認することを忘れないでください。使用と保守が簡単になります。

于 2016-01-25T18:50:17.893 に答える