プロジェクトの構成

エンタープライズのプロジェクトでは、複数の開発会社、地理的に離れた開発拠点、多数の開発者によって構成されます。 したがって分散リポジトリ管理ができないと、開発会社Aのコミットが開発会社Bのコミットによって破壊されるということを防ぐのは至難の業です。

また、単にリポジトリを分散しただけでは納品やテスト前の統合に神業的作業を要求されるので、きちんとした戦略に基づいて 分散開発モデルを設計する必要があります。

本書では、GitBucket（※1）にフォーカスした分散開発モデルの設計方法について取り扱います。

※1 GitBucketとは、GitHubクローンのOSSのWEBアプリです。

チームの分割とリポジトリの分割

まずはじめにチームを分割しましょう。 ここで分割したチーム数が、作成するリポジトリの数となります。

チームの分け方は、サブシステムごとのチーム + 方式チーム + DBAチームを基本としましょう。 役割としては、サブシステムごとのチームが業務機能を、 方式チームが業務以外の機能（共通的なコンポーネントやフレームワーク周り）を、 DBAチームはDBアクセス部分やDDLの生成などをそれぞれ担当します。

チームを分割したらGitBucket上にグループを作ります。 作るグループは分割したチームです。 グループを作ったら、そのグループのリポジトリ上で開発を行う開発者を登録していきます。 このようにすることで、グループに登録された開発者だけがグループ内のリポジトリに対して編集を行えるようになります。

また、チームとは別にビルド職人だけが編集可能なグループをGitBucket上に作りましょう。 ビルド職人だけが編集可能なグループの上にベースリポジトリを作っていきます。 ベースリポジトリとは、開発をしたソフトウェアを常にリリース可能な状態を保たせるためのリポジトリです。 ビルド職人のグループにこのベースリポジトリを置くことで、各開発者の誤ったコミットでリリースビルドが破壊されることを防ぐことができます。

ベースリポジトリを作成したら、各グループが編集するリポジトリを用意します。 GitBucketのForkという機能を使用して、ベースリポジトリから各グループにリポジトリをcloneすることで、リポジトリを用意します。 Forkでcloneしてきたリポジトリはサイトリポジトリと呼ぶようにします。 サイトリポジトリに実際のサイト毎の開発者のグループの編集権限を与え、ベースリポジトリはビルド職人のみ編集できるように設定します。

リポジトリをつなぐ

サイトリポジトリ内部での開発の仕方とサイトリポジトリからベースリポジトリへの反映とでそれぞれ方式が異なるので追って説明します。