リポジトリ

前編で説明したブランチの仕組みだけでも個人開発や小規模な共同開発では十分かも知れませんが、中規模以上の共同開発に供するには心許ない節があります。なぜなら、この仕組みは今のところ「変更の履歴が残るクラウドストレージ」以上の何物でもないからです。

共同開発とブランチ

共同開発ではプロダクトの複数の部分のそれぞれで同時に開発が進むことが一般的です。1 本のブランチの中に各部分の変更のコミットが入り乱れると当然コミットグラフは見にくくなりますが、問題はそれだけではありません。

Web 開発と 1 本のブランチ

Web アプリの開発においては、一般的には フロントエンド（ユーザーが直接見える部分）と バックエンド（データの授受と保管）をそれぞれ複数人が担当することになります。フロントエンドを開発するためにはバックエンドが正しく動かせる状態にある必要があります。フロントエンドは Web ページにデータをどう表示するかの部分を担いますが、肝心のデータ（画像やテキスト）がバックエンドから送られてこなければ Web ページの表示は見るも無惨に崩れてしまいます。

ここで、バックエンドのシステムに大きな変更が必要になったとしましょう。変更の途中では当然バックエンドは不完全であり、全く動かない可能性もあります。この場合、バックエンドの担当が優しければフロントエンドの開発を妨げないためにブランチの外側で（Git に頼らず）開発をすることになりそうです。しかしもしバックエンドが譲らない場合、フロントエンドの担当は正しく動く過去のバックエンドのシステムを手元で動かしながらブランチの外側で開発することになります。いずれにせよ、1 本のブランチの上に複数の部分の開発を共存させることは多大な困難を伴います。

ごく簡単にいうと「2 つ以上の部分の開発を同時に進められない場合がある」ことが一番の問題です。この問題を解決するために、Git ではブランチから別のブランチを「生やす」ことができます。ブランチ（枝）という名前から予測できたかも知れませんが、この機能が Git を便利なツールたらしめる最重要要素です。

リポジトリ

長らく「リポジトリ」という言葉を説明なしに用いてきました。リポジトリとは ある共通の根を持つブランチの集合 を表します。ブランチ一つ一つは「根っこの状態」と「その後の一連のコミット」の情報を持っていて、必要に応じてブランチから別のブランチを生やしたり（「切る」ともいう）、ブランチの変更同士を統合したりすることができます。

traP における大抵の開発では、リポジトリは以下のように運用されています。

• main ブランチを常にシステムとして健全に動くようにしておく
• main ブランチから「変更のブランチ」を生やし、その中で変更を済ませてから main に反映

この流れは GitHub Flow と呼ばれています。これによって、他の部分が健全に動くことを想定して各部分の開発に取り組むことができるようになります。中規模以上のプロジェクトでも、このリポジトリ・ブランチの仕組みがあれば十分に回るというわけです。

モノリポとポリリポ

ところが、共同開発を強力に支えるこのリポジトリの仕組みを以てしても管理が追いつかなくなるような大規模なプロジェクトは世の中に少なからず存在します。一つのプロジェクトを一つのリポジトリにおさめて管理することを「モノリポ」と呼び、それ自体が「ポリリポ」と呼ばれる対照的な管理形態の存在を暗示しています。

一つのプロジェクトを複数のリポジトリで分割して管理することにはいくつかメリットがあります。たとえば、開発者の権限はリポジトリごとに与えられるので、開発者が変更可能な領域を明確にできるという意味ではポリリポは良い選択です。

traP のプロジェクトとしては例えば traQ がポリリポを採用していて、フロントエンド（traQ_S-UI）とバックエンド（traQ）の 2 つのリポジトリに分かれています。一方、プロジェクトの初期段階ではチーム全体で設計の擦り合わせをしながら開発を進めていくためにモノリポの方が都合がよいことが多いです。モノリポとポリリポのどちらにも他方より良い点があり、どちらがより適しているかはプロジェクトの規模や内容によりけりです。