第1章 Git とは何か

バージョン管理という発明

コードを書いていると、ある時点で「昨日の状態に戻したい」「半年前の実装を見返したい」と思うことがある。 素朴にやるなら、report_20260401.docx report_20260402_final.docx report_20260402_final2.docx のように ファイル名に日付や "final" を足して保存していく方式になる。これが個人作業なら辛うじて回せるが、複数人で同じコードを編集し始めた瞬間に崩壊する。

バージョン管理システム (Version Control System, VCS) は、この「ファイルの変遷を記録する」作業をまるごと引き受けてくれる道具である。 いつ・誰が・どこを変えたかを履歴として保存し、過去の任意の時点に戻したり、複数人の変更を統合したりできる。 今の時代、コードを書く人にとってはエディタと同じくらいの必需品になっている。

Git は「分散型」のバージョン管理

Git が登場する前にも、CVS / Subversion (SVN) といったバージョン管理システムはあった。それらは集中型 (Centralized) と呼ばれ、 中央サーバーに 1 つのリポジトリ (履歴を保管する場所) を置き、各ユーザーはそこから最新をチェックアウトして作業する方式だった。 サーバーが落ちれば全員が手詰まりで、オフラインでは履歴をたどることすらできない。

Git は分散型 (Distributed) を採用している。全員のローカル PC に完全なリポジトリのコピーがある。 履歴もブランチもコミットも、手元だけで完結して操作できる。 他者と成果を共有したくなったタイミングで初めてネットワーク越しに同期する、という設計思想である。

MEMO

GitHub・GitLab・Bitbucket のようなサービスは、「その分散したリポジトリの 1 つを、みんながアクセスしやすい場所にホストしてくれるサーバー」という位置づけ。 Git そのものとは別物で、Git を使ってコードを共有するハブにすぎない。この点は第 5 章でもう一度触れる。

Git の中にある 3 つの場所

Git を理解するうえで一番大事なのが、リポジトリ内部にある 3 つの「場所」の違いである。 どれもファイルを保持する領域なのだが、それぞれ役割がはっきり分かれている。

Gitの三層モデル: 作業ツリー・ステージング・リポジトリ
Git の三層モデルと、層をつなぐ 2 つのコマンド

作業ツリー (Working Directory)

普段エディタでファイルを開いて編集している、あの場所のことである。 プロジェクトフォルダの中身そのもの。ここでの変更は、まだ Git の履歴には 1 ミリも反映されていない。

ステージング (Staging Area / Index)

作業ツリーとリポジトリの間にある中間層。 「これから作る次のコミットに含める変更」を、ここにいったん集める。git add は作業ツリーからステージングへ変更を送り込むコマンドである。

ステージングがあることで、たとえば「A のバグ修正」と「B の機能追加」を同時に手元で進めていても、 別々のコミットに切り分けて履歴に残せる。この選択的なコミットこそが Git の強さの 1 つでもある。

リポジトリ (Repository)

確定したコミットの履歴を保管している場所。プロジェクトフォルダ直下の .git/ ディレクトリがこれに相当する。 git commit はステージングに集めた変更を、ひとつのコミットとしてこのリポジトリに記録する操作である。

一度リポジトリに入ったコミットは、原則としてずっと残り続ける。 「昨日の状態に戻したい」というあの願いを叶えてくれるのは、この履歴があるからである。

POINT

3 つの場所と、層をつなぐ 2 つのコマンド (git add と git commit) の関係を頭に入れておけば、 この後の章で出てくるコマンドがどの層をどう動かしているのか、迷子になりにくくなる。

まとめ