33

Gitプロジェクトには、コンテンツが独立して作業されている2番目のプロジェクトが含まれています。

ユーザーが「親」のクローンを作成またはダウンロードしようとすると、サブプロジェクトも含める必要があるため、サブモジュールを小さいものに使用することはできません。

サブプロジェクトは活発に開発されているため、サブツリーのマージは使用できません。サブツリーのマージでは、これらの更新を元のプロジェクトにマージすることは非常に困難です。

このソリューションはSVNの世界では「ベンダーブランチ」として知られており、Gitで簡単に実行できるため、アドレス指定も必要ありません。中途半端なチュートリアルがネット上にたくさんあります。

それにもかかわらず、私はそれを機能させることができないようです。

誰かが（かなりお願いしますか？）あるプロジェクトが別のプロジェクト内に存在し、両方が同じ作業ディレクトリから開発および更新できる構造を作成する方法を説明できますか？理想的には[または、サポートされていない場合は、クライアントが「親」プロジェクトをダウンロードしようとしたときに、サブプロジェクト の最新バージョンを自動的に提供することが非常に重要です。

サブモジュールやサブツリーマージ、さらにはSVN：Externalsの使用方法を説明しないでください。このスレッドは、次のSOスレッドの派生物であり、何かが見落とされた場合は、そこに投稿してください。このスレッドは、ベンダーブランチの方法を理解しようとしています。より長く、より明確で、よりダミーの説明を受け取ると、私はより幸せになります。

4

3 に答える 3

40

「ベンダーブランチ」に関しては、サブモジュールが適していると思います。
submod の使用方法は次のとおりです... うーん、冗談です。

ちょっとした考え; あなたがしたい:

  • メインプロジェクトとサブプロジェクトの両方を同じディレクトリ内で開発する (これは「システムアプローチ」と呼ばれます: すべてのシステムを開発、タグ付け、マージします)
  • または、サブプロジェクトを「ベンダー ブランチ」(ベンダー外部コンポーネントの明確に定義されたバージョン、または「ファイルのセット」にアクセスできるようにするブランチ) として表示し、新しいものでのみ更新されます。その外部コンポーネントのリリースごとにバージョンを変更します。これは「コンポーネントアプローチ」と呼ばれ、すべてのシステムは、独自に開発された個別のコンポーネントのコレクションと見なされます)

2 つのアプローチには互換性がありません。

  • 最初の戦略は、サブツリー マージと互換性があります。プロジェクトとサブプロジェクトの両方で作業しています。
  • 2 つ目はサブモジュールで使用されますが、サブモジュールは構成(作業する必要があるタグのリスト) を定義するために使用されます: 各 git サブモジュールは、svn:externals とは異なり、特定のコミット ID に固定されています。構成を定義する(S C 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 の第一人者が、より適切な回答をここに投稿してくれることを願っています。

于 2009-04-20T20:28:28.610 に答える
7

山に戻る前に、ようやく数時間ネットにアクセスできるようになりました。あなたの状況を明確にするのに役立つ何かがあるかどうかを確認します。

私の（おそらく単純化された）理解は、（社内の）チームが外部ソースのフレームワークを使用してメインプロジェクトのコードを開発しているプロジェクトのプラグインを開発している（オフサイトの）ベンダーがいるということです。ベンダーはあなたのコードに変更を加えることはなく、おそらく最先端の開発は必要ありませんが、作業を開発およびテストするために安定したコードが必要です。あなたのチームはフレームワークに変更を加えませんが、プラグインに変更を加えることがあります。

  1. VonC (通常は非常に徹底的に物事を考えている) のように、Git があなたの要件に完全に適合するとは思いません。彼と同じように、サブツリー マージ パターンを使用するのが最も適していると思います。私は Git の第一人者ではありませんが、Git を幅広いニーズに合わせることには成功しています。たぶん、Git はあなたのニーズを満たしていません:

    • SVN を使用すると、1 つのリポジトリ内に複数のリポジトリを作成できます。これは、あなたにとって重要なようです。これは、externals または Vendor Branch パターンを使用して、目的に近づけることを意味すると思います。

    • Mercurial には、ネストされたリポジトリを使用するための拡張機能Forestがあり、これはあなたのメンタル モデルにより適しているようです。15 か月前に Mercurial ではなく Git を選びましたが、HG は安定しており、多くの用途で Git に匹敵すると思います。拡張機能がどれほど安定しているかはわかりません。

  2. 私があなたの状況にあった場合、2 つの Git リポジトリを使用します。1 つはプラグイン用で、もう 1 つは MainProject 用です。ベンダーはプラグイン リポジトリで開発を行い、残りの開発環境なしでプラグインの現在のバージョンをプルするリリース ブランチを用意します。そのブランチは、ベンダー ブランチとして MainProject リポジトリに取り込まれ、メインの開発ブランチにマージされます。 チームがプラグインの変更に取り組むとき、彼らはメインの開発ブランチから離れた機能ブランチでそれを開発し、パッチとしてベンダー リポジトリに提出します。 これにより、非常にクリーンなワークフローが得られ、セットアップと学習が比較的簡単で、開発履歴が分離されたままになります。

    私は議論をしようとしているわけではありませんが、単にこれがあなたの状況を理解するのに最も適していると言うだけです. これを設定する最も簡単な方法は、サブツリーのマージを使用することですが、これは変更を両方向に実行しません。これは、そのパターンを使用することに対する私の反対でした。

  3. チームがプラグインの開発に積極的に関与している場合、またはプロジェクトとプラグインの両方の開発履歴を 1 つの Git リポジトリに統合したい場合は、1 つの Git リポジトリを使用してください。こちら で説明されているように、ベンダーのレコードのプラグインとその履歴を随時抽出できます。これにより、意図したよりもカプセル化が少なくなる可能性がありますが、Git はカプセル化用に設計されていません。Git のデータ構造は、1 つのプロジェクト全体での変更の追跡に基づいています。

たぶん私はあなたの状況を誤解しており、これには当てはまりません。もしそうなら、私はお詫び申し上げます。あなたと VonC が解決した詳細に感謝します。これにより、私が最初にあなたの質問を理解しようとしていた多くの穴が埋められました。

于 2009-04-22T20:53:08.330 に答える