Gitサブモジュールの代替？

Gitサブモジュールを使用することは、私の開発ワークフローにとってどういうわけか面倒だと感じています。GitサブツリーとGitslaveについて聞いたことがあります。

• 複数のリポジトリプロジェクト用のツールは他にもありますか？また、それらをどのように比較しますか？
• これらのツールはWindowsで実行できますか？

どちらが最適かは、ニーズ、要望、ワークフローによって異なります。それらはある意味で半同形であり、特定のタスクのために他のものよりもはるかに使いやすいものもあります。

• gitslaveは、スーパープロジェクトとほぼ同時にサブプロジェクトを制御および開発する場合や、通常、すべてのリポジトリに同時にタグ付け、分岐、プッシュ、プルなどを行う場合に役立ちます。gitslaveは、私が知っているWindowsでテストされたことがありません。perlが必要です。

• git-submoduleは、サブプロジェクトを制御しない場合、またはサブプロジェクトが変更された場合でも特定のリビジョンでサブプロジェクトを修正したい場合に適しています。git-submoduleはgitの標準部分であるため、Windowsで機能します。

• git-subtreeは、gitの組み込みサブツリーマージ戦略のフロントエンドを提供します。単一リポジトリの「統合された」git履歴が必要な場合に適しています。サブツリーマージ戦略とは異なり、異なる（ディレクトリ）ツリーへの変更を元のプロジェクトにエクスポートして戻す方が簡単ですが、gitslaveやgit-submoduleの場合ほど自動ではありません。

• レポは理論的にはgitslaveに似ていますが、私が見つけたAndroid以外の操作については十分に文書化されていません。これはGoogleAndroid開発モデル専用であり、少数のgitコマンドのみをネイティブでサポートし（ただし、任意のコマンドを実行できます）、限定的なネイティブサポートは、たとえば、プッシュしてチェックアウトするための集中リポジトリをサポートしていません。ブランチはかなり難しいようです。

• kitenetのmrは、複数のバージョン管理システムを使用している場合に使用したいものですが、最小公分母のアプローチのため、ほとんどの場合gitのみのスーパープロジェクトに制限されています。任意のコマンドを実行する方法はありますが、それらは十分に統合されていません。

選択肢のリストに新たに追加されたのはGitX-Modulesです。ここで説明するように、Gitサブモジュールの一般的な欠点を回避することを目的としています。主な違いは、すべての同期がサーバー側で行われることです。そのため、エンドユーザーには、クローンを作成してプッシュする通常のGitリポジトリのみがあります。

私は現在、サードパーティのライブラリに関連するだけでなく、開発にサブモジュールを使用しています。サブモジュールを使用すると、特にマージまたはリベースの競合の原因となる場合に、作業を楽にする方法がいくつかあります。ls-treeを調べて、サブモジュールの競合に関係する2つのコミットを取得します。これはおそらく、サブモジュールの中で最も扱いにくい部分です。今のところ、スクリプトを使用すると、これをはるかに簡単に操作できるようになります。Gitの将来のバージョンでは、それらを処理するためのより優れたネイティブサポートが必要です。

お役に立てれば。

さまざまな言語に依存関係があるプロジェクトでGitサブモジュールを使用すると、同様の問題が発生しました。それらに対処するために、MDLR（ "Modular"）と呼ばれるツールを構築してオープンソース化しました。このツールは、Gitサブモジュールと同様の機能を備えた宣言型のバージョン管理されたGit依存関係を提供しますが、煩わしいワークフローはありません。GitHubリポジトリの手順/ダウンロードを使用して、インストールし、依存関係を管理できます。

いくつかのユースケースでは、次の2つの簡単なアプローチのそれぞれが好きです。

• ネストされたリポジトリ。ソフトウェアプロジェクトにプラグインメカニズムがあり、各プラグインが独自のサブディレクトリにある場合、これらのプラグインディレクトリをgit-ignoreし、ローカルファイルシステムでそれぞれを独自のgitリポジトリにするのが理にかなっています。このように、すべてのファイルは単一のディレクトリツリーを形成しますが、異なるgitリポジトリで管理されます。gitを混乱させることはありません。

• パッケージごとのリポジトリ。ある種のソースコードパッケージ管理システム（gem / bundler、npm、pearなど）を使用するソフトウェアプロジェクトの場合、再利用したコードを別々のgitリポジトリに配置し、それらからソースパッケージを作成するのが理にかなっています。次に、パッケージ管理ツールを使用してそれらを親プロジェクトにインストールします。親プロジェクトのgitリポジトリには、必要なパッケージとそのバージョンへの参照のみが含まれますが、これらのパッケージの実際のコードは、他のすべてのパッケージや外部ライブラリと同様にgit-ignoredされます。上で提案したネストされたリポジトリと比較すると、これは、インストールするパッケージのバージョンを指定できるため、より複雑なアプローチです。