Git サブモジュール

Git サブモジュールを使用すると、Git リポジトリを別の Git リポジトリのサブディレクトリとして保持できます。Git サブモジュールは、別のリポジトリの特定の時点におけるスナップショットに対する単なる参照です。Git サブモジュールによって、Git リポジトリで外部コードのバージョン履歴を組み込んで追跡できます。

Git サブモジュールとは

多くの場合、コード・リポジトリは外部コードに依存します。この外部コードは、いくつかの異なる方法で組み込めます。外部コードはメイン・リポジトリに直接コピー & ペーストできます。この方法には、外部リポジトリに対するアップストリームの変更がすべて失われるというデメリットがあります。外部コードを組み込むもう 1 つの方法は、Ruby Gems や NPM のような言語のパッケージ管理システムを使用することです。この方法には、元のコードがデプロイされるすべての場所でインストールとバージョン管理が必要になるというデメリットがあります。これらの推奨される組み込み方法は、どちらも外部リポジトリに対する編集や変更を追跡できません。

Git サブモジュールは、別の外部リポジトリ内の特定のコミットを指す、ホスト Git リポジトリ内のレコードです。サブモジュールは非常に静的で、特定のコミットのみを追跡します。サブモジュールは Git ref やブランチを追跡せず、ホスト・リポジトリが更新されても自動更新されません。サブモジュールをリポジトリに追加すると、新しい .gitmodules ファイルが作成されます。.gitmodules ファイルには、サブモジュール・プロジェクトの URL とローカル・ディレクトリの間のマッピングに関するメタデータが含まれています。ホスト・リポジトリに複数のサブモジュールがある場合、.gitmodules ファイルにはサブモジュールごとにエントリがあります。

Git サブモジュールを使用するタイミング

厳密なバージョン管理を外部の依存関係に実施する必要がある場合は、git サブモジュールの使用を是非ご検討ください。次で、git サブモジュールの最適なユースケースをいくつか紹介します。

• 外部コンポーネントまたはサブプロジェクトの変更が速すぎる、または今後の変更によって API が壊れる場合は、安全のためにコードを特定のコミットにロックできます。

• あまり頻繁に更新されないコンポーネントがあり、それをベンダーの依存関係として追跡する場合があります。

• プロジェクトの一部をサード パーティに委任して、その作業を特定の時間またはリリースで統合する場合。これも更新があまり頻繁でない際に機能します。

git サブモジュールの共通コマンド

git サブモジュールを追加する

git submodule add は、新しいサブモジュールを既存リポジトリに追加するために使用されます。次は、空リポジトリを作成して git サブモジュールを調べる際の例です。

1$ mkdir git-submodule-demo
2$ cd git-submodule-demo/
3$ git init
4Initialized empty Git repository in /Users/atlassian/git-submodule-demo/.git/

この一連のコマンドによって、新しいディレクトリ git-submodule-demo を作成してそのディレクトリに入り、新しいリポジトリとして初期化します。次に、サブモジュールをこの新しいリポジトリに追加します。

1$ git submodule add https://bitbucket.org/jaredw/awesomelibrary
2Cloning into '/Users/atlassian/git-submodule-demo/awesomelibrary'...
3remote: Counting objects: 8, done.
4remote: Compressing objects: 100% (6/6), done.
5remote: Total 8 (delta 1), reused 0 (delta 0)
6Unpacking objects: 100% (8/8), done.

git submodule add コマンドは、git リポジトリを指す URL パラメーターを取ります。ここでは、awesomelibrary をサブモジュールとして追加しました。Git はサブモジュールをすぐにクローンします。これで、git status によってリポジトリの現在の状態を確認できるようになりました。

1$ git status
2On branch main
3
4No commits yet
5
6Changes to be committed:
7  (use "git rm --cached <file>..." to unstage)
8
9 new file:   .gitmodules
10 new file:   awesomelibrary

2 つの新しいファイルが、リポジトリの .gitmodules と awesomelibrary ディレクトリに追加されました。.gitmodules の内容を確認すると、新しいサブモジュール マッピングが表示されます。

1[submodule "awesomelibrary"]
2 path = awesomelibrary
3 url = https://bitbucket.org/jaredw/awesomelibrary

1$ git add .gitmodules awesomelibrary/
2$ git commit -m "added submodule"
3[main (root-commit) d5002d0] added submodule
4 2 files changed, 4 insertions(+)
5 create mode 100644 .gitmodules
6 create mode 160000 awesomelibrary

Git サブモジュールのクローン作成

1git clone /url/to/repo/with/submodules
2git submodule init
3git submodule update

git submodule init

git submodule init の既定の動作は、マッピングを .gitmodules ファイルからローカルの ./.git/config ファイルにコピーすることです。これは冗長に思えるかもしれませんし、git submodule init の有用性に疑問を抱くかもしれません。git submodule init には、明示的なモジュール名のリストを受け入れる拡張動作があります。これによって、リポジトリ上の作業に必要な特定のサブモジュールのみをアクティブ化するワークフローが可能になります。これは、多数のサブモジュールがリポジトリにあっても、実行中の作業のためにすべてのサブモジュールを取得する必要がない場合に役立ちます。

サブモジュール ワークフロー

サブモジュールが親リポジトリ内で適切に初期化されて更新されると、スタンドアロン リポジトリとまったく同じように利用できます。つまり、サブモジュールには独自のブランチと履歴があります。サブモジュールに変更を加える際は、サブモジュールの変更を公開してから親リポジトリのサブモジュールへの参照を更新することが重要です。awesomelibrary の例を取り上げて、いくつか変更を加えていきます。

1$ cd awesomelibrary/
2$ git checkout -b new_awesome
3Switched to a new branch 'new_awesome'
4$ echo "new awesome file" > new_awesome.txt
5$ git status
6On branch new_awesome
7Untracked files:
8  (use "git add <file>..." to include in what will be committed)
9
10 new_awesome.txt
11
12nothing added to commit but untracked files present (use "git add" to track)
13$ git add new_awesome.txt
14$ git commit -m "added new awesome textfile"
15[new_awesome 0567ce8] added new awesome textfile
16 1 file changed, 1 insertion(+)
17 create mode 100644 new_awesome.txt
18$ git branch
19  main
20* new_awesome

ここでは、ディレクトリを awesomelibrary サブモジュールに変更しました。いくつかの内容を含む新しいテキスト ファイル new_awesome.txt を作成して、この新しいファイルをサブモジュールに追加してコミットしました。ここで、ディレクトリを親リポジトリに戻して親リポジトリの現在の状態を確認しましょう。

1$ cd ..
2$ git status
3On branch main
4Changes not staged for commit:
5  (use "git add <file>..." to update what will be committed)
6  (use "git checkout -- <file>..." to discard changes in working directory)
7
8 modified:   awesomelibrary (new commits)
9
10no changes added to commit (use "git add" and/or "git commit -a")

git status を実行すると、親リポジトリが awesomelibrary サブモジュールへの新しいコミットを認識していることがわかります。これはサブモジュール リポジトリの責任であるため、特定の更新については詳述しません。親リポジトリは、サブモジュールをコミットに固定することだけを考慮しています。これで、git add と git commit をサブモジュールで実行することで、親リポジトリを再び更新できます。これによって、すべてがローカル コンテンツで良好な状態になります。チーム環境で作業している場合は、サブモジュールと親リポジトリの各更新を git push することが重要です。

サブモジュールを扱う際の混乱とエラーの一般的なパターンは、リモート ユーザーに更新をプッシュし忘れることです。たった今行った awesomelibrary の作業を再確認すると、親リポジトリの更新のみがプッシュされていました。別の開発者が最新の親リポジトリをプルすると、その親リポジトリは、私たちがサブモジュールをプッシュし忘れたために、これらの開発者がプルできない awesomelibrary のコミットを指し示していることになります。これによって、リモートの開発者のローカル リポジトリが壊れます。この失敗シナリオを回避するには、必ずサブモジュールと親リポジトリをコミットしてプッシュするようにしてください。

結論

Git サブモジュールは、git を外部の依存関係管理ツールとして活用する強力な方法です。Git サブモジュールは詳細機能でありチーム メンバーが習得するまで時間がかかる場合があるため、使用前にその長所と短所を比較検討してください。