コミットIDの活用例
前回記述した通り、「スーパープロジェクト」から「サブモジュール」をチェックアウトすると、「スーパープロジェクト」が管理している「サブモジュール」の「コミットID」が指す「コミットオブジェクト」から、プロジェクトのファイル群をチェックアウトします。また、「サブモジュール」の「HEAD」と「サブモジュール」の「コミットID」は、別々に管理されます。
これにより、「サブモジュール」の「リモートリポジトリー」が別のユーザーにより更新されたとしても、常に「スーパープロジェクト」が期待する「サブモジュール」のプロジェクトのファイル群をチェックアウトすることができます。
1.サブモジュールの利用形態
「サブモジュール」は、「スーパープロジェクト」と関係性の強いリポジトリーを「スーパープロジェクト」で一括管理する仕組みです。ここでは例として、以下のような「サブモジュール」の利用形態があるとします。
| リポジトリーの種類 | 概要 |
|---|---|
| スーパープロジェクト | アプリ本体（実行可能ファイル） |
| サブモジュール | アプリで使用するライブラリー |
「サブモジュール」は「スーパープロジェクト」から生成されるアプリで使用するライブラリーであり、アプリが動作するのに必須のライブラリーです。
このライブラリーの役割は、データの処理です。
また、このライブラリーは、異なるのリポジトリーで生成されるアプリでも使用されています。
このアプリは日本語に翻訳されておらず、あるユーザーがこのアプリの翻訳作業を行うとします。
ちなみに「サブモジュール」の「リモートリポジトリー」は、以下のようになっています。
2.スーパープロジェクトのチェックアウト
ユーザーはアプリの翻訳作業を行うため、「スーパープロジェクト」をクローンしました。また、アプリをビルドして動作確認を行うため、「サブモジュール」もクローンしました。
この時「Git」は、「スーパープロジェクト」が管理している「コミットID」が指す「コミットオブジェクト」から、各「サブモジュール」をチェックアウトします。
翻訳作業に必要なファイルは、「スーパープロジェクト」からチェックアウトしたファイル群の中にあります。
これでユーザーはアプリの翻訳作業を行うことができます。
作業が終わったら、「スーパープロジェクト」の「リモートリポジトリー」に反映します。
3.サブモジュールのリモートリポジトリーが更新されていたら？
「2.」のタイミングで、「サブモジュール」の「リモートリポジトリー」が別のユーザーによって更新されていたとします。
しかもその更新は、「スーパープロジェクト」が生成するアプリと互換性がなく、別途対応作業が必要です。（アプリのビルドができない状態）
ただし、新しいライブラリーへの対応による翻訳作業の追加はありません。
もし「サブモジュール」の仕組みを利用せず、その対応作業が別のユーザーの担当だった場合、アプリの翻訳作業を行うユーザーは、アプリの動作確認を行うことができません。
以前のコミットからチェックアウトすることも可能ですが、どのコミットからチェックアウトすればよいのか、確認作業が必要になります。
従って、翻訳作業以外の作業も必要になってしまいます。
4.コミットIDを利用する
「3.」のような状況になっても、各「サブモジュール」をどの「コミットオブジェクト」からチェックアウトすればよいのか「スーパープロジェクト」が把握しています。
「スーパープロジェクト」から各「サブモジュール」をチェックアウトすれば、アプリの動作確認が可能なプロジェクトのファイル群が使用できます。
アプリの翻訳作業を行うユーザーは、アプリの翻訳を行い、アプリの動作確認を行うことができます。
5.コミットIDの更新
「3.」の後、別のユーザーがアプリを新しいライブラリーに対応する作業を行いました。新しいライブラリーとセットでビルドすることが前提になるため、そのユーザーは「スーパープロジェクト」で管理している「コミットID」を更新し、「スーパープロジェクト」の「リモートリポジトリー」に反映します。
これで、「スーパープロジェクト」をクローンした際、新しいライブラリーに対応したアプリをビルドできるようになります。
