【Git図解】バージョン管理ツールとは

Gitとは

Gitはバージョン管理システムの1つです。
バージョン管理システムとは、ファイルの変更履歴を管理するシステムです。
もう少し詳しく説明すると、「誰が」「いつ」「どのファイルを」「どのように」変更したかを記録するシステムです。
変更内容の全てが保存されているため、変更前の状態に戻したり、変更内容を確認することができます。

代表的なバージョン管理ツール

バージョン管理ツールは集中型と分散型の2種類に大別されます。
以下にそれぞれの代表的なツールの一例をあげます。

集中型

CVS
Subversion (SVN)

分散型

Git
Mercurial

集中型と分散型の違いは後述しますが、Gitは分散型であることを覚えておいてください。

Gitを図解

ここから分散型バージョン管理ツールであるGitを説明していきます。
言葉で詳細を説明しても分かりにくいと思いますので、まずイメージをつかむために以下の簡略化した図を見てください。

青色がデータを保持する場所で、赤色の矢印はデータの流れになります。
詳しくは次章から説明していきますが、簡単に単語の意味を説明しておきます。

まずリポジトリとはデータを保存する場所という意味です。
なのでリモートリポジトリは、遠くにあるデータの保存場所、つまりサーバ上にあるデータの保存場所という意味合いです。
反対にローカルリポジトリは、自分の作業PC上にあるデータの保存場所となります。

インデックスは一時保存場所と思ってもらえば大丈夫です。
実際にデータを編集する場所がワーキングツリーとなります。

赤色の矢印に記載された英単語はGitで仕様するコマンドです。
これらのコマンドはよく使いますし、エンジニアどうしの会話でもよく出ますので覚えておきましょう。
コマンドの役割は次章で説明します。

データの流れ

まず大まかな流れを把握するため、サーバにデータを保存するまでの流れを簡単に説明します。

自分のPCでデータを変更し、サーバに反映させるまでの流れを考えます。
データは以下の順番で進み、サーバにたどり着きます。

ワーキングツリー
インデックス
ローカルリポジトリ
リモートリポジトリ

次章では、この流れをコマンドと照らし合わせて説明します。

代表的なコマンドの役割

add

まず、自分のPCでデータを変更するので、図でいうと一番右のワーキングツリーで変更が行われます。
次に変更内容を一時保存場所のインデックスに置きます。
この変更内容をインデックスに移す操作をaddといいます。

commit

インデックスに置いた変更内容をローカルリポジトリに反映させます。

push

ローカルリポジトリの変更内容をサーバのリモートリポジトリに反映させます。

pull

このコマンドはリモートリポジトリからデータを取得したいときに使います。
リモートリポジトリの内容をローカルリポジトリとワーキングツリーに反映させます。

以上がよく使う代表的なコマンドです。
英単語が並ぶので難しく思うかもしれませんが、ただサーバとデータをやり取りする工程に名前をつけているだけですね。

なんとなく流れがつかめたでしょうか？
分からなくなったら図に戻ってみてください。

pullとfetchの違い

違いが分かりにくいコマンドにpullとfetchがあります。
結論からいうと、pull = fetch + merge です。

先ほどpullはリモートリポジトリの内容をローカルリポジトリに反映させると説明しました。
実はこの操作には2つの手順が含まれています。

最新のリモートリポジトリの内容を取得する。
取得した最新のリモートリポジトリの内容をローカルリポジトリに反映させる。

上記の1がfetchで、2はmergeと呼ばれるコマンドになります。

リモートリポジトリの内容をローカルリポジトリに反映したい場合はpull、リモートリポジトリの最新の状態を知りたいだけならfetchと思ってもらえれば問題ありません。

集中型と分散型の違い

Gitを含む分散型はリポジトリをサーバ上だけでなく、作業PC上のローカルリポジトリでも管理します。

一方、集中型ではリポジトリをサーバ上でのみ管理します。
つまり上図のローカルリポジトリとインデックスがありません。
そのためローカルの作業スペースから直接リモートリポジトリにデータを保存することになります。

ではローカルリポジトリがあるメリットとはどういったものでしょうか。

分散型のメリットとデメリット

分散型のメリット

まず分散型のメリットからです。
分散型の場合はローカルにもリポジトリがあるため、以下の点で集中型よりも優れています。

自分の仕事が進めやすい作業単位でコミットできる。
簡単に自分の作業履歴を確認できる。
サーバが故障した時に復元率が高い。
サーバとネットワークが繋がっていなくても、いつも通り作業ができる。

1つ1つ説明していきます。

自分の仕事が進めやすい作業単位でコミットできる

集中型の場合はコミットするとサーバのリモートリポジトリに変更が反映されてしまいます。
サーバのデータが変更されると、そのデータを参照するチームメンバー全員に影響が出てしまいます。
ですので集中型の場合は好き勝手にコミットすることはできません。

ところが分散型の場合は変更をコミットすると、まずローカルリポジトリに変更が反映されるため、いきなりサーバに変更が反映されません。
そのため自分の好きなタイミングでコミットしてもチームメンバーに迷惑をかけずに済みます。

例えば画面Aを作っている時、ボタンAの機能が完成したタイミングでコミット、ボタンBの機能が完成したタイミングでコミット。
そして最後にpushすることで2つに分けてコミットしていた変更を合わせてサーバに反映することができます。

コミットを細かく分けすぎてしまったけれどもサーバの変更履歴には「画面Aの新規作成」とだけ残したい場合はpushするタイミングでstashという機能を使えばコミット履歴を1つにまとめることができます。

簡単に自分の作業履歴を確認できる

ローカルリポジトリの変更履歴をたどることで、すぐに自分の作業履歴を確認できます。
集中型の場合は、リモートリポジトリにあるチームメンバー全員の変更履歴の中から自分の変更を探さなければなりません。

サーバが故障した時に復元率が高い

集中型では履歴を復元することができませんが、分散型の場合は誰かのローカルリポジトリから作業履歴も含めて復元できます。

大きいプロジェクトや運用期間の長いプロジェクトでは必ず履歴を確認しますので、履歴が復元できるのは大きなメリットとなります。

サーバとネットワークが繋がっていなくても、いつも通り作業ができる

次のような場面をイメージしてみてください。
あなたは画面Aと画面Bの作成を依頼されています。
まず画面Aが完成しました。
次に画面Bの作成を進めたいです。
後から見返した時のために画面Aで変更したコードと画面Bで変更したコードは分けておきたいですが、集中型ではサーバとネットワークが繋がっていなければリモートリポジトリに変更をコミットできないため、画面Aの変更内容が手元に残ったままになってしまい、画面Bの作業と切り分けることができません。

ファイルをコピーして別ファイルで画面Bの対応を進めることもできますが、サーバに変更を反映する時にどの変更が画面Aかなど見直すのが非常に手間です。

分散型であれば、サーバとネットワークが繋がっていなくともローカルリポジトリにコミットすることで、画面Aと画面Bの変更を簡単に分けることができます。