Git プロジェクトには、そのコンテンツが独立して作業されている 2 番目のプロジェクトが存在します。
サブモジュールは小さいものには使用できません。ユーザーが「親」を複製またはダウンロードしようとするときには、サブプロジェクトも含める必要があるためです。
サブプロジェクトが活発に開発されているため、サブツリーのマージは使用できません。サブツリーのマージにより、それらの更新を元のプロジェクトにマージすることが非常に困難になります。
このソリューションは SVN の世界では「ベンダー ブランチ」として知られており、Git では非常に簡単に実行できるため、対処する必要すらないと言われています。ネット上には中途半端なチュートリアルがあふれています。
それにもかかわらず、うまく動作しないようです。
誰か（本当にお願いします）プロジェクトが別のプロジェクト内に存在し、両方を同じ作業ディレクトリから開発および更新できる構造を作成する方法を教えてください。理想的には（または、サポートされていない場合は非常に重要です）、クライアントが「親」プロジェクトをダウンロードしようとすると、最新バージョンサブプロジェクトを自動的に作成します。
サブモジュールやサブツリーマージ、あるいはSVN:Externalsの使い方を説明しないでください。このスレッドは以下のSOスレッド何か見逃したものがあれば、ぜひ投稿してくださいそこにはこのスレッドは、ベンダー ブランチの使用方法を理解しようとするものであり、より長く、より明確で、よりわかりやすい説明をいただければ、より満足します。
ベストアンサー1
「ベンダー ブランチ」に関しては、サブモジュールが最適だと思います。
サブモジュールの使用方法は次のとおりです... うーん、冗談です。
ちょっとした考えですが、あなたが望むのは:
- メインプロジェクトとサブプロジェクトの両方を同じディレクトリ内で開発する（これを「システムアプローチ「: すべてのシステムを開発、タグ付け、マージします)
- または、サブプロジェクトを「ベンダーブランチ」（ベンダーの外部コンポーネントの明確に定義されたバージョン（または「ファイルセット」）にアクセスできるブランチであり、その外部コンポーネントのリリースごとに新しいバージョンにのみ更新されます。これは「コンポーネントアプローチ「システム全体は、独自に開発された個別のコンポーネントの集合体として見なされます」
2 つのアプローチには互換性がありません。
- 最初の戦略はサブツリーマージと互換性があり、プロジェクトとサブプロジェクトの両方で作業します。
- 2番目はサブモジュールで使用されますが、サブモジュールは定義するために使用されます構成（作業に必要なタグのリスト）：各gitサブモジュールは、svn:externalsとは異なり、特定のコミットIDに固定されており、これにより、構成（SのようにＣM: 「ソフトウェア構成管理"）
私は2番目のアプローチが好きです。なぜなら、ほとんどの場合、プロジェクトとサブプロジェクトがある場合、ライフサイクル異なります (同じリズムで開発されておらず、同時にタグ付けされておらず、同じ名前が付けられていません)。
あなたの質問でそのアプローチ (「コンポーネントベース」) を実際に妨げているのは、「両方とも同じ作業ディレクトリから開発および更新できる」という部分です。
ほとんどの IDE は複数の「ソース」ディレクトリを処理するのに完全に対応しており、サブプロジェクトの開発は専用の環境で実行できるため、その要件を再検討することを強くお勧めします。
samgoody 氏は次のように付け加えています。
Joomla と ModX の両方に対応する eMap プラグインを想像してください。プラグインと Joomla 固有のコード (eMap の一部ではなく Joomla の一部) は、プラグインが Joomla 内にある間に開発されます。すべてのパスは相対的で、構造は固定されており、各プロジェクトに独自のライフサイクルがあるにもかかわらず、一緒に配布する必要があります。
私の理解が正しければ、開発環境（作業中のファイルセット）が配布環境（リリースプラットフォームに同じファイルセットがコピーされる）とまったく同じ構成になっていると思います。
すべては粒度の問題に帰着します:
- 両方のファイル セットが、一方がなければ他方も存在できない場合は、それらを 1 つの大きなプロジェクト (およびサブツリー マージ) として扱う必要がありますが、そのためには、タグ付けして 1 つにマージする必要があります。-一方が他方 (単独で開発できる) に依存している場合は、それらを独自の Git リポジトリとプロジェクトに配置する必要があります。最初のファイルは、サブモジュールとして 2 番目のファイルの特定のコミットに依存します。サブモジュールが最初のコンポーネントの適切なサブツリーで定義されている場合は、すべての相対パスが尊重されます。
samgoody 氏は次のように付け加えています。
元のスレッドにはサブモジュールに関する問題がリストされていました。主に、GitHub のダウンロードにサブモジュールが含まれていないこと (私にとっては重要)、およびサブモジュールが特定のコミットで停止してしまうことです。
GitHubのダウンロードが最近問題になっているかどうかはわかりません。ガイド: サブモジュールを使った開発記事では次のように言及しています:
何よりも良いのは、サブモジュールのパブリッククローンURLを登録してあるので、
my-awesome-frameworkフォークをクローンする人がサブモジュールをプルダウンするのに問題がないことですmy-fantastic-plugin。コマンド
$ gh submodule init
$ gh submodule update
サブモジュールを現在のリポジトリにプルします。
「特定のコミットで止まってしまう」という点については、それがサブモジュールの最大の目的であり、構成最新の不安定な可能性のあるファイル セットではなく、(コンポーネントのタグ付けされたバージョンのリスト) を使用します。
samgoody はこう言っています:
私はサブツリーとサブモジュールの両方を避ける必要があり（質問を参照）、このアプローチが正当化されるのであれば、あまり議論せずにこのニーズに対処したい。
あなたの要件は完全に正当なものであり、私はその正当性を判断するつもりはありません。私の以前の回答は、より大きなコンテキストを提供し、一般的な SCM ツールで通常利用できるオプションを説明するためだけにここにあります。
ここでの答えはサブツリーのマージですが、メイン プロジェクトのファイルに対して行われたコミットのみをマージし、サブプロジェクトに対して行われたコミットはマージしないことを意味します。そのような部分的なマージを管理できる場合は、それが正しい方法であると思います。
しかし、subtree-merge や submodule を使用せずに、必要なことを実行するネイティブ Git の方法は見つかりません。
真の Git の第一人者が、より適切な回答をここに投稿してくれることを願っています。