図3は、分散型バージョン管理システムを使う際のワークフロー例だ。分散型バージョン管理システムでは、変更を加えたファイルの情報をまずローカルのリポジトリにコミットしていき、ある程度変更点がまとまったらそれをpushという形でほかのリポジトリに送信する。また、pullという機能を使うことで、ほかのリポジトリで行われた変更点を自分のリポジトリに取ってくることもできる。
|
| 図3 分散型バージョン管理システムのワークフロー |
分散型バージョン管理システムには、次のような利点がある。
- 競合を考えずにコミットが行える
- オフライン環境でも利用できる
- 派生物の作成が容易
分散型バージョン管理システムでは、各開発者がそれぞれ自分専用のリポジトリを持つため、コミット時には自分が編集しているファイルを他者が同時に編集していたという事態（競合と呼ばれる）が発生しない（もちろん、pushやpullを実行する際にはpush/pull対象のリポジトリとで競合を解消する必要はある）。また、ローカルにリポジトリを作成するため、ネットワークが利用できない環境でもコミットを行うことができる。
そして、「中央リポジトリ」が存在せず、、他の開発者が加えた変更を自由に自分のリポジトリにマージできるため、特定の変更点だけを反映させた派生物を作りやすい。たとえば、分散型バージョン管理システムを利用する場合、特定のリポジトリを「マスターリポジトリ」とし、そこに各開発者がそれぞれのリポジトリで加えた変更点をマージして成果物を作成する、というケースが多いが、このマスターリポジトリをベースに、別の変更を加えて独自の成果物を作成することもできる。また、プロジェクトが複数のグループに分かれている場合などは、それぞれのグループごとに変更点をマージしたリポジトリを用意し、最終的にそこからそれぞれのグループの成果物をマージする、といった階層的なプロジェクト運営を行うこともできる。
分散型バージョン管理システムを集中型バージョン管理システムのように使う
分散型バージョン管理システムでは複数のリポジトリが存在するために一見難しく見えるが、次のようなルールで運用することで、集中型バージョン管理システムと同じように利用することもできる（図4）。
- すべての変更点を集積するマスターリポジトリを用意する
- 各開発者は、ファイルに変更を加える前にマスターリポジトリから変更点をpullする（集中型バージョン管理システムのアップデートに相当）
- ローカルリポジトリに変更点をコミットした後、必ずマスターリポジトリへ変更点をpushする（集中型バージョン管理システムのコミットに相当）
- それぞれのリポジトリはマスターリポジトリ以外に対してpush/pullを行わない
|
| 図4 個人リポジトリ間のpush/pullを考慮しなければ、分散型バージョン管理システムは集中型バージョン管理システムとほぼ同様に運用できる |
分散型バージョン管理システムに不慣れな場合、まずは上記のような集中型のルールでプロジェクトを運営し、必要に応じてリポジトリの分岐や個人リポジトリ間のpush/pullを行うなど、分散型のメリットを活用できる体制に移行していくとよいだろう。なお、集中型の運用をする場合でも、Gitを使えば「競合を考えずにコミットが行える」、「オフライン環境でも利用できる」というメリットが得られる。