パイソンエンジニア部
「rebase しますか？」とAIに聞かれて、一瞬手が止まったことはないでしょうか。
私は最近、コードを書くときに Claude Code（ターミナルの中で動くAIエージェント）を使っています。ファイルの保存も、履歴の記録も、枝分かれした作業の切り替えも、話しかければAIが裏でGitを操作してくれます。便利な一方で、AIはときどきこちらに判断を求めてきます。「この変更は rebase で取り込みますか、それとも merge ですか」「force push してよいですか」。
このとき、自分でコマンドを打てる必要はありません。けれど「それが何を意味して、何が危ないのか」を判断できないと、Yes とも No とも言えずに固まってしまいます。逆に、その意味さえ分かっていれば、手順は知らなくてもAIに的確に指示できます。
つまりAIと組む時代に要るのは、Gitの操作スキルではなく Gitの「概念の地図」 です。実装は任せ、方針と判断は自分が握る。エンジニアというより、技術の分かるマネージャーの立場でGitと付き合う。この連載は、その地図を手に入れるための記事です。第1回では、Gitが何を解決する道具なのか、そしてGitを形づくっている2つの設計思想を整理します。
TL;DR
- Gitは変更の歴史を安全・正確に記録し、いつでも戻れるようにする道具。ゲームのセーブポイントに近いですが、無限に作れて枝分かれもできます。
- 設計の根っこには2つの思想があります。履歴を全員が丸ごと持つ 分散 と、差分ではなく全体の写真を撮る スナップショット。この2つがGitの軽さと頑丈さを生んでいます。
- AIと組む時代に要るのは、コマンドの操作スキルではなく 概念の地図。意味さえ分かれば、手順を知らなくてもAIに的確に指示でき、「rebaseしますか？」のような問いにYes/Noを返せます。
ファイル名で消耗するのを、もうやめる
Gitを知らないころ、私はこういうファイルをよく作っていました。
企画書_最終版.docx 企画書_最終版_修正.docx 企画書_最終版_修正_田中さん指摘反映.docx 企画書_最終版_本当にこれで最後.docx
どれが本物なのか分からなくなります。手で複製するやり方には、避けられない限界があります。いつ・誰が・なぜ変えたのかが残らない。消したコピーは二度と戻らない。複数人が同時に触れば上書きし合う。
Gitはバージョン管理システム（変更の履歴を記録し、いつでも元に戻せるようにする仕組み）の一つで、この限界をまとめて解決します。やっていることを一言でいうと、こうです。
プロジェクト全体の「歴史」を、安全に・正確に・何度でも記録し、いつでも参照・復元できるようにする。
イメージとしてはゲームのセーブポイントが近いです。区切りのいいところで状態を保存し、失敗したらそこに戻る。Gitではこの保存を「コミット」と呼びます。ただしゲームより自由度が高く、セーブは無限に作れて、過去のセーブはすべて残り、しかも一直線ではなく枝分かれして並行して進められます。
Gitは「失敗を恐れる」ための道具ではなく、「安心して失敗できる環境」を作る道具です。こまめにコミットしておけば、何を壊しても過去に戻れる。だから大胆に実験できます。AIに思い切ったコードを書かせて試す、という今の働き方と相性がいいのは、この性質があるからです。
Gitの形は、2つの思想から決まっている
Gitは2005年、Linux OS（世界中のサーバーを動かしているOS）の生みの親である Linus Torvalds が作りました。世界中の何千人もの開発者が関わる巨大プロジェクトを高速にさばく、という目的が最初にあり、その目的が設計思想を決めています。細かなコマンドの前に、この思想を2つだけ押さえると、あとの理解が一気に楽になります。
(↓リーナス・トーバルズ) 
思想1：履歴は「全員が丸ごと持つ」
Gitより前の主流は、履歴を1か所のサーバーに集めておく中央集権型でした。Gitはこれをやめ、複製した時点で各自の手元に全履歴のコピーが渡る 分散 を選びました。
flowchart TB subgraph central["中央集権型"] S["中央サーバー<br/>履歴は中央だけ"] --- P1["PC"] & P2["PC"] & P3["PC"] end subgraph dist["分散型・Git"] R["リモート GitHub等"] R <--> Q1["PC<br/>全履歴を保持"] R <--> Q2["PC<br/>全履歴を保持"] R <--> Q3["PC<br/>全履歴を保持"] end
手元にすべての歴史があるので、ネットがつながっていなくてもコミットも履歴の閲覧も枝分かれもできます。どれか1台でも生きていれば歴史は失われません。GitHub のような「みんなが集まる置き場」は技術的にはただの慣習で、そこが落ちても各自の手元で開発は止まりません。
「速い」と「分散」は、実は同じことの裏表です。ネットの往復を待たずに手元だけで完結するから速い。Gitの軽快さの正体はこの分散にあります。
思想2：差分ではなく「スナップショット」を撮る
多くの旧来ツールは、各バージョンを「前の版からの変更点（差分）」として記録していました。しかしGitは違って、コミットのたびに その時点のプロジェクト全体の写真（スナップショット） を撮ります。
【差分方式（旧来）】 版1: ファイルA, B, C の完全な中身 版2: 「Aの3行目を変更」という差分だけ → 最新の状態を知るには、版1から差分を全部足し算する必要がある 【スナップショット方式（Git）】 コミット1: [A v1] [B v1] [C v1] コミット2: [A v2] [B v1] [C v1] ← Aだけ変えた。B,Cは前の中身を「指す」だけ
ポイントは、変わっていないファイルを保存し直さず、前のものを指すだけにすることです。
ここで当然こう思います。「全部の写真を撮ったら、容量が爆発するのでは？」。鋭い直感で、もし本当に毎回まるごとコピーしていれば正しい心配です。けれどGitは二層構造になっています。
私たちに見せるモデルは分かりやすい「スナップショット」のまま。その裏で、似たファイルどうしを差分圧縮して、ディスク上は小さく抑えています。「人には完全な写真を見せ、内部では賢く圧縮する」——この割り切りがGitの設計の妙です。容量の話は実際に手元で確かめられるので、連載の第3回で数字を見ながら確認します。
「概念の地図」を手に入れると、何が変わるか
冒頭の話に戻ります。この2つの思想を押さえているだけで、AIとの会話が成立し始めます。
たとえばAIが「rebase で取り込みますか」と聞いてきたとします。rebase は履歴を作り直す操作で、後の回で詳しく扱いますが、要点は「コミットを別物に作り替える＝すでに他人と共有した歴史に使うと食い違いが起きる」ということです。この一行の意味さえ分かっていれば、「まだ自分しか触っていないから rebase でいい」「もう共有済みだから merge にして」と判断して返せます。自分でコマンドを打つ必要はありません。
AIが履歴を壊してしまったときも同じです。AIに曖昧な指示を投げて試行錯誤させるより、ひと言「reflog で戻して」と言えるかどうかで結果が変わります。reflog という安全網が存在すると知っていることが、的確な依頼につながる。知識は、自分が手を動かすためではなく、AIに正しく頼むために要るのです。
頼み方も具体的になります。「いい感じにやっておいて」と丸投げするのではなく、こう言えます。
- 「main は汚さずに、新機能は別のブランチで試して」
- 「さっきの状態に戻して。ただし今書いた変更は残したまま」
- 「この変更だけ取り消して、ほかはそのままで」
どれも、自分でコマンドを打つわけではありません。けれど「ブランチ」「戻す」「この変更だけ」という概念の言葉で頼めると、AIは迷わず動けます。曖昧な一言で試行錯誤させるより、結果がまっすぐ返ってきます。
だからこの連載で覚えてほしいのは、コマンドの暗記ではありません。「コミットとは何か」「ブランチとは何か」という、頭の中の1枚の地図です。手順はいつでもAIに聞けます。AI時代に廃れないのは、打てる手ではなく「何を頼むか分かる頭」のほうです。
なお、ここから先の回では実際にターミナルでGitやGitHub CLI（GitHubをコマンドラインから操作する公式ツール gh）を動かして確かめます。導入や初期設定がまだの方は、次回の環境構築の回から始めてください。すでに動く方は、その次の回からそのまま手を動かせます。
まとめ
第1回として、Gitの全体像を思想から整理しました。
- Gitは「変更の歴史」を安全・正確に記録し、いつでも戻れるようにする道具。ゲームのセーブポイントに近いが、無限に作れて枝分かれもできる。
- 設計の根っこには2つの思想がある。履歴を全員が丸ごと持つ「分散」 と、差分ではなく全体の写真を撮る「スナップショット」。この2つがGitの軽さと頑丈さを生んでいる。
- AIと組む時代に要るのは操作スキルではなく概念の地図。意味が分かればAIに的確に指示でき、判断できる。
次回は、手を動かす準備として、Git と gh のインストールと初期設定を済ませます。ここを一度きり仕込んでおけば、第3回以降の「実際に .git の中を覗く」実習にそのまま入れます。
