GitサブモジュールとGitクローン


18

私はGitHubでオープンソースプロジェクトに取り組んでいます。

サブディレクトリ/ Vendorがあり、その中にいくつかの外部ライブラリのコピーがあります。プロジェクトの元のメンテナーは、このディレクトリを外部ライブラリの新しいコピーで時々更新しました。

1人の開発者が、このコピーgit submoduleに置き換えるというアイデアのあるプルリクエストを送ってきました。

そして、それが良いアイデアかどうかを検討しています。

Gitサブモジュールの長所:

  • サブモジュールは、同様のシナリオ用に特別に設計されました
  • 次の更新中に上書きされるベンダーへの偶発的なコミットの可能性を削除します

Gitサブモジュールの短所:

  • gitサブモジュールがメンテナーからプロジェクトをクローン/プルする人に複雑さを押し付けているようです(クローンを作成してプロジェクトの作業を開始するには、追加の手順が必要です: "git submodule init"、 "git submodule update"

これについてはどう思いますか?

もう一つ。この問題は、外部依存関係が非常に限られているかなり小さなサイズのライブラリです。今のところ、どんなビルドツールでもやり過ぎだと思います。


4
あるいはgit clone --recursive、サブモジュールコマンドを実行でき、実行する必要はありません。他の誰もこのちらつきを言及していません。私が知っているほとんどの人は、サブモジュールがREADMEでこれを宣伝しています。
レヴィ・モリソン

回答:


9

サブモジュールの代替手段はを使用することgit subtreeです。これにより、git submodule複雑さをエンドユーザーに押し付けることなく利点が得られます。サードパーティのリポジトリはメインプロジェクトツリーにマージされますが、次のような方法で保存されたメタデータがあります。

  • 興味深い変更が行われた場合、後でサードパーティのリポジトリを抽出します
  • サードパーティのリポジトリから新しいアップデートにマージします(上書きではなくマージに注意してください)

サブモジュールを理解するほど洗練されていないGitユーザーの場合、サブツリーアプローチにより、プロジェクトのクローンを他のクローンよりも難しくすることはありません。ドキュメントからの短い宣伝文:

サブツリーを使用すると、サブプロジェクトをメインプロジェクトのサブディレクトリに含めることができます。オプションでサブプロジェクトの履歴全体を含めることもできます。

たとえば、ライブラリのソースコードをアプリケーションのサブディレクトリとして含めることができます。

サブツリーをサブモジュールと混同しないでください。サブモジュールは同じタスクを対象としています。サブモジュールとは異なり、サブツリーは特別な構造(.gitmoduleファイルやgitlinksなど)がリポジトリに存在する必要はなく、リポジトリのエンドユーザーに特別なことを強制したり、サブツリーの仕組みを理解したりする必要はありません。サブツリーは、任意の方法でプロジェクトと共にコミット、分岐、およびマージできるサブディレクトリです。

私はサブモジュールを使用して作業中のプロジェクトをセットアップしていましたが、すべての人のクローンでサブモジュールを最新の状態に維持するのは大変な作業でした。最近、どこでもサブツリーを使用するように変更し、それらの問題はなくなりました。

git-subtreeはgit/contribディレクトリの一部であり、個別にインストールする必要があることに注意してください。


4

サブモジュールを使用する1つの欠点は、Github(および他の多くのサービス)のtarballまたはzipアーカイブにサブモジュールのソースが含まれていないことです。つまり、アーカイブは自己完結型ではありません。これは、リポジトリが小さく、JavaScriptライブラリに依存する静的HTMLサイトのようなビルドスクリプトが実際にない場合に問題になります。


3

これは、サブモジュールを使用するのに理想的な場所です。リポジトリのサイズと複雑さを軽減し、外部ライブラリを新しいバージョンに簡単に更新できるようにします。

使用方法を理解するのは難しくなく、この状況ではかなり一般的に使用されるので、サブモジュールと何をすべきかをプロジェクトのREADMEに書き留めてください。それを。サブモジュールを備えたリポジトリに初めて遭遇したとき、10〜15分で立ち上げて実行しましたが、それ以降何をすべきかを理解するのに問題はありませんでした。


1
これに対する補足として、アプリケーションの初期化に失敗した場合、サブモジュールが初期化されたことを確認するためにチェックを入れて、そうでない場合はわかりやすいエラーメッセージを提供することができます。
ジョナサンリッチ

1
また、サブモジュールファイルのないzipアーカイブに関するLekensteynの回答も参照してください。これは、サブモジュールがコードを公に提供している場合、おそらく最良のアプローチではないことを意味しますが、クローンが保証されているプラ​​イベートコードには適しています。それ以外の場合は、サブツリーを優先します。
エンジニア

3

サブモジュールを使用すると、コードをローカルで変更できなくなり、外部リポジトリへの依存関係が作成されます。あなたがいる場合は必ず、あなたはします決してライブラリをカスタマイズしたり、地元のバグ修正をしたいんや外部のサーバがすることを確認することができ、常に新しいコピーのクローンを作成したい場合、彼らは移動するための方法です利用できます。

要するに、あなたは単にライブラリを使用したいのですか、それともあなたのコードベースの一部と考えていますか?それらが「あなたの」コードでない場合、なぜそれらはバージョン管理にあり、インストールするのに必要なものだけではないのですか?


6
サブモジュールは、ローカルの変更を妨げるものではありません。それどころか、これらの変更により、それらの変更を追跡し、異なるプロジェクトでライブラリの異なるバージョン(微調整またはライブラリリリース)を使用できます。
スティーブファローズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.