はじめに

gitのプロジェクトにsubmoduleというもので管理する方法があります。
操作方法は調べたら色々ありますが、目的がいまいち掴めなかったので理解できるレベルで整理しました。
ここではsubmoduleの使用の仕方ではなく、使用して何がありがたいのかを記載します。

submoduleのメリット

submodleを使用したプロジェクトの利点は簡単に記載する以下になります。

・サブモジュールごとのコミット位置を記録できる
・サブモジュール毎に作っていくことができる。

プロジェクトで、submoduleごとの特定のコミット位置を、プロジェクトにセットできるということです。
バックエンドとフロントエンドを別々のプロジェクトで作っていたとして、それぞれのタイミングでテストして管理したい場合、プロジェクトのsubmoduleとして管理するという使用の仕方ができます。
つまりプロジェクト間でこういうセットで管理するという場合にとても有効だということです。

依存関係の明確化：プロジェクトが他のリポジトリに依存している場合、その依存関係を明示的に管理できます。これにより、必要な依存リポジトリの正確なバージョンを確保できます。
独立した開発：サブモジュールは独自の開発ライフサイクルを持っています。つまり、サブモジュール（例えばフロントエンドやバックエンドのリポジトリ）は、親プロジェクトから独立して更新やテストを行うことができます。
統合管理の容易さ：親プロジェクトでは、サブモジュールの特定のバージョンに対する参照を管理します。これにより、プロジェクト全体が一貫した状態であることを保証しつつ、各サブモジュールの更新を容易に取り込むことができます。

submoduleを使用している場合のクローン例

以下は特定位置の状況をプロジェクトよりセットする方法です。
今回操作記載は対象外でいきなり感がありますが、submoduleのコミット位置のセットの趣旨から記載しています。

リポジトリをクローンする:

git clone --recurse-submodules <リポジトリURL>

git clone コマンドを実行すると、デフォルトでリモートリポジトリのデフォルトブランチ（多くの場合は main または master、リポジトリによって設定されている)に依存します。
　
2. 特定のブランチにチェックアウトする:
リポジトリ内に移動し、希望するブランチにチェックアウトします。

cd <リポジトリ名>
git checkout <ブランチ名>

特定のブランチに切り替えますが、サブモジュールがある場合、この時点でサブモジュールの状態は自動的には更新されません。サブモジュールを更新するには、次のステップが必要です。
　
3. サブモジュール内の同期:
以下を行います。

git submodule update --init --recursive

以上のプロセスにより、プロジェクトを特定のブランチやコミットに基づいてクローンし、すべてのサブモジュールを含めて正しくセットアップすることができます。この手順は、開発者がプロジェクトの特定の状態を取得したい場合や、サブモジュールを含む複雑なプロジェクトを扱う際の手段となります。

(3の補足)
サブモジュールも含めたプロジェクト全体を、そのブランチで指定された特定の状態に同期させたい場合、git submodule update --init --recursive を実行します。このコマンドは、サブモジュールを含め、すべてのサブモジュールが親プロジェクトの.gitmodulesファイルに記載された特定のコミットまたはブランチにチェックアウトされるようにします。これにより、サブモジュール内のサブモジュールも含め、プロジェクト全体が一貫した状態になります。

おわりに

submoduleは便利そうですが、ただそのメリットを享受するために、gitのsubmoduleの操作に慣れる必要があります。また改めて整理したいと考えています。

参考記事