バージョン管理システムというとSubversionやCVSが有名だが、近年急速にユーザーを増やしている「Git」は、分散型のバージョン管理システムとして支持を集めている。本稿では、はじめてGitに触れる方のために、その導入方法や基本的な使い方を解説する。
バージョン管理システムというとSubversionやCVSが有名だが、近年急速にユーザーを増やしているバージョン管理システムに「Git」がある。GitはLinuxカーネルの開発リーダーとして知られるリーナス・トーバルズ氏が中心となって、Linuxカーネルの開発に使用する目的で開発した分散型バージョン管理システムである。2005年に開発が開始されて以来さまざまなプロジェクトでの採用が進み、現在ではPerl 5やRuby on Rails、Android、Wine、X.orgなど、有名な大規模プロジェクトで採用されるに至っている。
本記事では、このGitを使用するのに必要な「分散型バージョン管理システム」の基本的な考え方を紹介するとともに、Gitの導入方法や基本的なGitの使い方について解説する。
GitはLinuxカーネル開発で用いられることを前提に開発されており、次のような特長を備えている。
この中でもGitの大きな特長となっているのが「分散型」という点だ。Gitはプロジェクトにかかわる各開発者がそれぞれローカルにリポジトリを持ち、必要に応じてリポジトリ間で変更点をやり取りすることでソースコードなどの管理を行う(図1)。一方、バージョン管理システムとして有名なSubversionやCVSは、1つのリポジトリにすべての開発者がアクセスする「集中型」と呼ばれるアーキテクチャを採用している(図2)。
図3は、分散型バージョン管理システムを使う際のワークフロー例だ。分散型バージョン管理システムでは、変更を加えたファイルの情報をまずローカルのリポジトリにコミットしていき、ある程度変更点がまとまったらそれをpushという形でほかのリポジトリに送信する。また、pullという機能を使うことで、ほかのリポジトリで行われた変更点を自分のリポジトリに取ってくることもできる。
分散型バージョン管理システムには、次のような利点がある。
分散型バージョン管理システムでは、各開発者がそれぞれ自分専用のリポジトリを持つため、コミット時には自分が編集しているファイルを他者が同時に編集していたという事態(競合と呼ばれる)が発生しない(もちろん、pushやpullを実行する際にはpush/pull対象のリポジトリとで競合を解消する必要はある)。また、ローカルにリポジトリを作成するため、ネットワークが利用できない環境でもコミットを行うことができる。
中央リポジトリが存在せず、、ほかの開発者が加えた変更を自由に自分のリポジトリにマージできるため、特定の変更点だけを反映させた派生物を作りやすい。例えば、分散型バージョン管理システムを利用する場合、特定のリポジトリを「マスターリポジトリ」とし、そこに各開発者がそれぞれのリポジトリで加えた変更点をマージして成果物を作成する、というケースが多いが、このマスターリポジトリをベースに、別の変更を加えて独自の成果物を作成することもできる。また、プロジェクトが複数のグループに分かれている場合などは、それぞれのグループごとに変更点をマージしたリポジトリを用意し、最終的にそこからそれぞれのグループの成果物をマージする、といった階層的なプロジェクト運営を行うこともできる。
分散型バージョン管理システムでは複数のリポジトリが存在するために一見難しく見えるが、次のようなルールで運用することで、集中型バージョン管理システムと同じように利用することもできる(図4)。
分散型バージョン管理システムに不慣れな場合、まずは前記のような集中型のルールでプロジェクトを運営し、必要に応じてリポジトリの分岐や個人リポジトリ間のpush/pullを行うなど、分散型のメリットを活用できる体制に移行していくとよいだろう。なお、集中型の運用をする場合でも、Gitを使えば「競合を考えずにコミットが行える」「オフライン環境でも利用できる」というメリットが得られる。
Copyright © 2010 OSDN Corporation, All Rights Reserved.