Git：Dev Basics／Keyword

連載目次

　Gitは分散型のバージョン管理システムで、オープンソース開発プロジェクトなどで広く利用されている。中央集中型のバージョン管理システムとは異なり、リモートリポジトリ、ローカルリポジトリの2種類のリポジトリで管理し、ブランチを使用したノンリニア（並列）な開発が可能になっており、複数の組織や個人が参加する開発プロジェクトのバージョン管理に適している。

　このGit仕様を採用して構築されたGitHubが、数々のオープンソースプロジェクトで利用されている。

Gitとは：分散型のバージョン管理システム

　Gitは、Linuxの主要開発者でもある、リーナス・トーバルズ氏らによって開発が行われているオープンソースなバージョン管理システムだ。

　その一番の特徴は「分散型」であること。ここでいう「分散」とは、あるプロジェクトに参加しているコンピュータの全てが、そのプロジェクトのリポジトリ（ソースコードを含むファイルそのものやディレクトリ、それらの更新履歴などを記録した「貯蔵庫」）全体の複製を所有するということだ。中央のサーバで全て管理する形式に比較すると、分散性がより高く、独立性の高い個人や組織が協調開発するときに都合がよい。またこの形式では、1台のコンピュータがクラッシュしてもプロジェクト全体の内容が完全に失われることが避けられるという利点もある。

分散型のバージョン管理

　リポジトリには「ローカルリポジトリ」と「リモートリポジトリ」の2種類がある。前者は名前の通り、ローカルなPC上に存在するリポジトリのことだ。後者はネットワーク上に存在するリポジトリであり、複数の開発者によって共有される。

　リモートリポジトリ（Gitサーバ）からプロジェクトをローカルなPCにクローン（複製）すると、PC上のローカルリポジトリにそのプロジェクトに関する情報の全てが複製される。PCでは、ソースコードの編集を進めたり、以前の履歴を参照したり、変更をコミットしたりといったことをサーバとは独立して行える。

　そして、変更した内容を他の開発者と共有できる状態になったら、サーバに対してその内容を「プッシュ」することで、変更をプロジェクトに反映できる。

ローカルリポジトリとリモートリポジトリ

　Gitのローカルリポジトリとリモートリポジトリをさらに詳しく見てみよう。

ローカルリポジトリ

　Gitの管理下で、ローカルに作業をするときには、次の三つの要素が関係してくる。

1. Gitリポジトリ
2. ステージングエリア
3. ワークスペース（作業ディレクトリ）

　Gitリポジトリには、Gitが管理するさまざまな情報が格納される。ワークスペースには開発者が実際に編集するファイルが含まれる。ステージングエリアとは、開発者が行った変更をGitリポジトリに反映（コミット）する前に登録を行う領域のことだ（インデックスともいう）。ステージングエリアは、複数のファイルの編集後に、それらを関連性のあるファイルごとにリポジトリにコミットするといった場合に便利に使える。

ワークスペース／ステージングエリア／Gitリポジトリ

　ワークスペースで編集を行い、それをステージングエリアに登録し（「git add」コマンド）、Gitリポジトリにコミットする（「git commit」コマンド）のが一般的な流れとなる。こうした作業を繰り返しながら、開発に一区切りが付いたところで、それらをリモートリポジトリへと反映（プッシュ）する。

リモートリポジトリ

　リモートリポジトリはネットワーク上に存在し、複数の開発者で共有される。リモートリポジトリは、プロジェクトの種類や規模によって、一つだけの場合もあれば、複数の場合もある。

　ここでは分かりやすい例を一つだけ紹介しよう。これは共有リポジトリが一つだけで、そこに複数の開発者のマシンがぶら下がる形で作業をする場合だ。以下に例を示す。

単一のリモートリポジトリを複数の開発者で共有

　この場合、個々の開発者がリモートリポジトリの内容を更新する権限を持ち、コミットした内容をリモートリポジトリにプッシュしていく。ただし、既に他の開発者がプッシュしている場合には、他の開発者によって反映された変更を自分のリポジトリに取り込んで（マージして）テストなどを行い、プロジェクトが壊れていないことを確認してからプッシュする必要がある。

　リモートリポジトリが複数になる場合に、どのような作業の流れになるかについては「ProGit」の「5.1 Git での分散作業 - 分散作業の流れ」などを参照してほしい。

ブランチを使用したノンリニア開発

　ブランチとは、アプリの開発／運用時に何らかの時点でバージョン管理の履歴を枝分かれさせて、独立してバージョン管理を行うためのものだ。Gitでは開発当初には、この変更履歴の流れが一つだけ存在し、これを「masterブランチ」と呼ぶのが一般的だ。

　例えば、リリース版のアプリを表すブランチ、新機能を実装するためのブランチ、バグフィックスを行うためブランチ、実験的な機能を試してみるブランチなどが生まれては消えていく。Gitではブランチ切り替えも簡単なことから、これらのブランチを並列（ノンリニア）に進行させながら快適にアプリ開発を進められる。

　ブランチを別のブランチへと合流させることで、あるブランチの内容を別のブランチに取り込める。下図の例なら、リリース版のアプリにバグが見つかった時点で、そのブランチからHotfix用のブランチを作成して、バグが修正できたら、それをリリース版のブランチに取り込むといった具合だ。

ブランチ

　本フォーラムの読者の方の多くが慣れ親しんであろうVisual StudioでもGitを利用したバージョン管理が可能になるなど、Gitは.NET開発者にとっても必須の知識となりつつある。以下のドキュメントなども参考にして、ぜひともマスターしよう。

「Dev Basics／Keyword」