15章サブモジュール
1個のユーティリティライブラリやライブラリセットを必要とする多数のアプリケーションを作ることはよくある。そのような場合、個々のアプリケーションは、分割の論理的な単位だからとか、コードのオーナーシップの問題からといった理由で、専用のGitリポジトリで開発、共有、分岐、マージしたいところだろう。
しかし、このような形でアプリケーションを分割すると問題が起きる。個々のアプリケーションは共有ライブラリの特定のバージョンに依存しているので、どのバージョンを使っているかを管理しなければならない。そうでなければ、誰かが間違えてテストされていないバージョンにライブラリをアップグレードしたときに、アプリケーションが動作しなくなる。さらに、ユーティリティライブラリはそれを使っているアプリケーションと無関係に開発されているわけではない。それぞれのアプリケーションで必要な新機能を追加するために、アプリケーションの開発者がユーティリティライブラリに細かい修正を加えているのが普通だ。そして、最終的にはライブラリを使っているほかのアプリケーションの開発者たちにも新機能をシェアしようと思うだろう。ユーティリティライブラリとはそういうものだ。
この問題に対処するための方法としては、部分チェックアウト、プロジェクトへの依存コードの直接インポート、プロジェクトのサブフォルダへの依存プロジェクトのコピーなどのさまざまな方法が使われている。しかし、これらはエレガントな方法とは言えない。これらを「ハック」と見る人々さえいる。
Gitがこの問題に対処するために使っているのはサブモジュール(submodule)だ。サブモジュールとは、Gitリポジトリの一部になっているが、独自のソースコントロールリポジトリも持っているプロジェクトのことである。Gitは、gitlinkを使ってほかのGitリポジトリを直接参照していることを示す。この章では、まずgitlinkの使い方を説明してから、サブモジュール操作の複数のテクニックを示していく。最後に、サブモジュールに代わる方法として ...