【初心者向け】イメージで掴むGitの基本

Git 2016年1月6日

概要

ソフトウェアエンジニアならば、開発においてほとんどの人がバージョン管理システム(Version Control System(長いので以下VCS))を利用します。VCSの有名なものに、SVN(エス・ブイ・エヌ、サブバージョン)やGit(ギット)などがあります。今回は、SVNよりも後発でありながら、特にプログラム開発環境でその真価を発揮するGitについてお話したいと思います。

そもそもバージョン管理システム(VCS)って？

あるファイルを更新した時に、前の状態に戻したくなったことはありませんか？
また、ファイル名に日付を足したりして、いくつものファイルを生成して管理した経験はありませんか？
はたまた、同じファイルを複数人で編集して、ワケガワカラナイヨ状態になったことは？
そういったことを簡単に出来るようにした便利なシステムのことを、VCSと言います。

何故Gitを使うの？

概要でも述べたように、VCSにはいくつかありますが、その中でもGitはとても優れたツールだと僕は思います。しかしながら、GitはSVNなどに比べて、少しばかり学習コストが高い。そのため、便利でありながらも、未だにSVNで開発を行っている人達が沢山います。
SVNでも悪くはないのですが、Gitを使いこなせるようになれば開発効率はかなり上がりますし、デキるエンジニアのスキルセットとしても求められてきています。是非ここでイメージを掴んでおきましょう。

Gitの構成

Gitの構成は分散型リポジトリにあたります。はい、意味がわかりませんね。ここでまず二つの大きな概念を覚えましょう。『リモート』と『ローカル』です。

リモートとローカル

以下の図を見てください。

Gitを使う場合、大抵は図のような構成になっています。まずここで覚えて欲しいのは、リモートには『Remote区origin町のmasterさん』という『神様(ソースコード)』がいるということです。そしてこのRemote区やLocal区のことをリポジトリと呼んでいます※1。
Gitにおいて、この神様は誇張でも何でもなく神様であり、全てのソースコードの祖となる存在です。大切に扱いましょう。

Checkout(チェックアウト)

さて、これだけではまだ我々はGitの恩恵を受けることはできません。ここから神様をLocal1とLocal2にchackoutしましょう。
以下の図を見てください。

ローカルに神様がやってきましたね。チェックアウトとは言いましたが、実際はコピーです。リモートとの違いは、今のところoriginがあるかないかです。これは便宜上のもので、そういうものだと思っていてください。

これにより、それぞれのリポジトリに神様がいる状態になりましたね。これこそが分散型リポジトリと言われる所以です(たぶん)。
ユーザはこのローカルにコピーしてきた神様を元に、ソースを改修するわけですが、ここでブランチという機能を利用します。

Branch(ブランチ)

ついにGitの醍醐味でもあるbranchがやってきました。ブランチとは、Gitで管理しているソースのスナップショットのことで、実はmasterもブランチの中の1つとなっています。そしてブランチは、masterを含めた他のブランチから生成することができ、これを巷では「ブランチを切る」なんて言ったりします。
以下の図を見てください。

ローカル1の中で、masterからbranch_aとbranch
_bをそれぞれ作成してみました。ブランチを切る時点では、新しく作成されたブランチは元のブランチと同じ状態になっています。
ちなみに、branch_aの左の『*』は、今このブランチにいるよという意味です。今いるブランチを変更するには、git checkout branch_bのようにチェックアウトすることで、branch_bに移動することが出来ます。

さて、ブランチを切るとどんな良いことがあるのでしょう。試しに、今いるbranch_aに変更を加えてみましょう。

何やら作業コピーという怪しげなものが出てきました…

Add(アド)

先の操作によって、branch_aの作業コピーに赤追加という変更が現れました。Gitでは、管理下にあるファイルの変更は初めに作業コピー(Working Copy)に入ります。そしてこの状態では、まだbranch_aには何も変更が反映されていません。それでは、どうやってこの変更をブランチに反映させることができるのでしょうか？

実は、まだここからは直接ブランチへ変更を加える事は出来ません。その下準備として、この赤追加をインデックスへaddします。

addしたことによって、作業コピーにあった赤追加が跡形もなく消え、代わりにインデックスに現れました。つまり、移動したんです。
ちゃっかり説明も無しにインデックスが登場しましたが、これは先ほどの作業コピーと似たもので、作業コピーよりもさらにブランチに近い側の変更を管理する場所です。
何故インデックスを挟む必要があるのか、疑問に思う方もいらっしゃるかと思います。ここでは深くは触れませんが、この領域があることによって、ブランチへの変更点を柔軟に取捨選択したり出来る等のメリットがあるのです。今はとりあえず、変更した後はaddすると覚えておきましょう。

Commit(コミット)

さてさて、ついにブランチへ変更を反映させましょう。使用する操作はcommitです。説明もなんですから、早速commitしてみましょう。

上の図のように、branch_aに赤追加が反映されました。その証拠にバージョンが変わったでしょう？小さくて見辛いかもしれませんが、実際もこんな感じの控えめ具合なので問題ありません。ただ、ver.2のような風に記録するわけではなく、
commit 08e026f301afd6c2176e1f2ba6f902f8cdeb0193
のようにハッシュで管理されています。