分散バージョン管理システムGit入門：Beginner's Guide（1/3 ページ）

バージョン管理システムというとSubversionやCVSが有名だが、近年急速にユーザーを増やしている「Git」は、分散型のバージョン管理システムとして支持を集めている。本稿では、はじめてGitに触れる方のために、その導入方法や基本的な使い方を解説する。

[松島浩道，SourceForge.JP Magazine]

　バージョン管理システムというとSubversionやCVSが有名だが、近年急速にユーザーを増やしているバージョン管理システムに「Git」がある。GitはLinuxカーネルの開発リーダーとして知られるリーナス・トーバルズ氏が中心となって、Linuxカーネルの開発に使用する目的で開発した分散型バージョン管理システムである。2005年に開発が開始されて以来さまざまなプロジェクトでの採用が進み、現在ではPerl 5やRuby on Rails、Android、Wine、X.orgなど、有名な大規模プロジェクトで採用されるに至っている。

　本記事では、このGitを使用するのに必要な「分散型バージョン管理システム」の基本的な考え方を紹介するとともに、Gitの導入方法や基本的なGitの使い方について解説する。

分散バージョン管理システムとは？

　GitはLinuxカーネル開発で用いられることを前提に開発されており、次のような特長を備えている。

• 開発者各自がローカルにリポジトリを持つ「分散型」アーキテクチャを採用
• 高速かつ柔軟にブランチの作成やマージが可能
• Linuxカーネルのような巨大なプロジェクトでも十分な速度で動作
• 変更履歴は暗号化されて保存され、改ざんができない
• 主要部分はCで記述されており、各種スクリプト言語から利用できるラッパーも用意されている
• 独自プロトコルのほかWebDAVやrsync、ssh経由でリモートのリポジトリにアクセスできる

　この中でもGitの大きな特長となっているのが「分散型」という点だ。Gitはプロジェクトにかかわる各開発者がそれぞれローカルにリポジトリを持ち、必要に応じてリポジトリ間で変更点をやり取りすることでソースコードなどの管理を行う（図1）。一方、バージョン管理システムとして有名なSubversionやCVSは、1つのリポジトリにすべての開発者がアクセスする「集中型」と呼ばれるアーキテクチャを採用している（図2）。

（左）図1 各開発者がリポジトリを持つ分散型バージョン管理システム
（右）図2 1つのリポジトリにすべての開発者がアクセスする集中型バージョン管理システム

図3 分散型バージョン管理システムのワークフロー

　図3は、分散型バージョン管理システムを使う際のワークフロー例だ。分散型バージョン管理システムでは、変更を加えたファイルの情報をまずローカルのリポジトリにコミットしていき、ある程度変更点がまとまったらそれをpushという形でほかのリポジトリに送信する。また、pullという機能を使うことで、ほかのリポジトリで行われた変更点を自分のリポジトリに取ってくることもできる。

　分散型バージョン管理システムには、次のような利点がある。

• 競合を考えずにコミットが行える
• オフライン環境でも利用できる
• 派生物の作成が容易

　分散型バージョン管理システムでは、各開発者がそれぞれ自分専用のリポジトリを持つため、コミット時には自分が編集しているファイルを他者が同時に編集していたという事態（競合と呼ばれる）が発生しない（もちろん、pushやpullを実行する際にはpush／pull対象のリポジトリとで競合を解消する必要はある）。また、ローカルにリポジトリを作成するため、ネットワークが利用できない環境でもコミットを行うことができる。

　中央リポジトリが存在せず、、ほかの開発者が加えた変更を自由に自分のリポジトリにマージできるため、特定の変更点だけを反映させた派生物を作りやすい。例えば、分散型バージョン管理システムを利用する場合、特定のリポジトリを「マスターリポジトリ」とし、そこに各開発者がそれぞれのリポジトリで加えた変更点をマージして成果物を作成する、というケースが多いが、このマスターリポジトリをベースに、別の変更を加えて独自の成果物を作成することもできる。また、プロジェクトが複数のグループに分かれている場合などは、それぞれのグループごとに変更点をマージしたリポジトリを用意し、最終的にそこからそれぞれのグループの成果物をマージする、といった階層的なプロジェクト運営を行うこともできる。

分散型バージョン管理システムを集中型バージョン管理システムのように使う

　分散型バージョン管理システムでは複数のリポジトリが存在するために一見難しく見えるが、次のようなルールで運用することで、集中型バージョン管理システムと同じように利用することもできる（図4）。

• すべての変更点を集積するマスターリポジトリを用意する
• 各開発者は、ファイルに変更を加える前にマスターリポジトリから変更点をpullする（集中型バージョン管理システムのアップデートに相当）
• ローカルリポジトリに変更点をコミットした後、必ずマスターリポジトリへ変更点をpushする（集中型バージョン管理システムのコミットに相当）
• それぞれのリポジトリはマスターリポジトリ以外に対してpush／pullを行わない

図4 個人リポジトリ間のpush／pullを考慮しなければ、分散型バージョン管理システムは集中型バージョン管理システムとほぼ同様に運用できる

　分散型バージョン管理システムに不慣れな場合、まずは前記のような集中型のルールでプロジェクトを運営し、必要に応じてリポジトリの分岐や個人リポジトリ間のpush／pullを行うなど、分散型のメリットを活用できる体制に移行していくとよいだろう。なお、集中型の運用をする場合でも、Gitを使えば「競合を考えずにコミットが行える」「オフライン環境でも利用できる」というメリットが得られる。