バージョン管理とは何か

動いていた状態が、どこにも残っていない

昨日まで動いていたコードが、今日いじったら動かなくなる。しかもどこをいじったのか自分でも分からない。エディタの取り消しを連打しても、途中で保存しているので戻りきりません。

たとえば CSS のレイアウトを直しているとします。うまくいかないので display を変え、position を変え、余白の数値をあちこち触る。30 分後、画面はさらに崩れています。ここで「触る前に戻したい」と思っても、変更した場所が 8 か所に散らばっていて、どれを元の値に戻せばいいのか分かりません。

失われているのはコードではありません。「動いていた状態」という情報です。バージョン管理は、まずこれを守るための仕組みです。チーム開発のための道具だと説明されがちですが、順番は逆で、一人で書いている自分を過去の自分から守るところから始まります。

フォルダをコピーしても、意味では戻せない

バージョン管理を知らないうちは、フォルダをコピーして名前を付けます。

myapp/
myapp_backup2/
myapp_20260210_ok/
myapp_final_fix/

数日は持ちますが、じきに 3 つの理由で行き詰まります。どれが動く版か名前からは判断できないこと。2 つのフォルダを並べても、40 ファイルのどこが違うのか目では分からないこと。そして「ログイン機能の変更だけ取り消して、そのあとのバグ修正は残す」ができないことです。

最後のひとつが決定的です。フォルダのコピーは時点でしか区切れず、意味では区切れません。

コミットは、その時点の全体を 1 枚に写す

Git は変更を保存すると、コミットという記録を 1 つ作ります。冒頭の図解のとおり、コミットは鎖のようにつながり、それぞれが 1 つ前を指します。

ここで多くの人が誤解します。コミットが持っているのは前回からの差分ではなく、その時点のプロジェクト全体です。

コミットA ← コミットB ← コミットC
 全ファイル   全ファイル   全ファイル

写真に近いと考えてください。1 コミットが 1 枚で、変えていないファイルも全部写っています。だからどのコミットにも単独で戻れます。手前の記録を順に適用し直す必要はありません。

写す範囲がプロジェクト全体であることには、もう 1 つ意味があります。ある機能を作るとき、HTML と CSS と JavaScript を同時に直すのは普通です。意味の上では 1 つの作業なので、Git ではまとめて 1 つのコミットにします。取り消すときも 3 ファイル分がまとめて戻ります。ファイル 1 つずつ履歴を持つクラウドストレージとの差はここです。

コミットには、記録した人と日時、そして 1 行のメッセージが付きます。

解説

コードは何をしているかを教えてくれますが、なぜそうしたかは教えてくれません。「この API が特定の順番でしか動かないため」と書き残せる場所は、メッセージだけです。

コミットは完成の宣言ではない

始めたばかりの人がいちばんよくやるのは、コミットを溜め込むことです。「機能が完成してからまとめて」と考えて 3 日分を 1 つにすると、戻れる場所が「3 日前」か「今」しか無くなります。メッセージも「いろいろ修正」としか書けません。

コミットは完成品を出す操作ではなく、途中経過に印を付けているだけです。しかも他人には一切見えません。「ここまでは動いている」と思った瞬間に打ちます。関数を 1 つ書き終えた、表示の崩れを直した、その程度で構いません。