Git って何？
35分で8回「セーブ」した夜と、4分で取り消した作り直し
Git は、作ったものの「セーブポイント」です。このサイトとゲームの実際の履歴をたどりながら、セーブして、戻して、枝分かれさせるところまでを説明します。
この記事は 2026年10月22日時点の情報です2026年1月25日の夜10時12分。このサイト usuilab.com は、まだ「ブラウン管テレビ」の見た目をしていました。
私は Claude Code に、テレビをもっと本物っぽくしてほしいと頼んでいました。直してもらって、見て、また頼む。その繰り返しが、Git という道具の中に、時刻つきでそのまま残っています。
22:12 リアルなブラウン管TV風デザインに変更 22:18 ヘッダー追加 & ボタン配置修正 22:25 ナビホバー修正 & CRTエフェクト & 言語切替 22:29 ホバーエフェクト修正 22:33 Fix project card hover effect 22:37 Add dedicated power button with power icon 22:43 Photorealistic TV design: deeper shadows, realistic textures 22:47 Add V-shaped TV antenna and adjust TV proportions (taller)
35分で8回。電源ボタンを足して、影を深くして、最後に V 字のアンテナを生やしています。一つ一つが、Git でいう「コミット」です。ゲームでいえば、セーブです。
このノートは「はじめての開発」の1本目として、Git が何をしてくれるのかを、私の実際の履歴を見せながら説明します。コマンドは最後に5つだけ出てきます。先に「何のためにあるのか」が分かれば、コマンドはあとから覚えれば十分です。
- Git は、ファイルの変更を「いつ・何を・なぜ」つきで記録して、いつでも前の状態に戻せるようにする道具
- AI に大きな作り直しを任せる前にセーブしておけば、気に入らなかったときに丸ごと戻せる。私は4分で戻した
- ブランチを使うと、本番を触らずに別の世界で試せる。このサイトの記事も、いまそうやって書いている
- 152回このサイトのコミットの数（2026年10月22日まで）
- 8回1月25日の夜、35分の間のコミット
- 4分AI が作り直したゲームの場面を、丸ごと戻すまで
- 661件Fall in Love で、まだセーブしていない変更
Git は、作ったもののセーブポイント
Git の公式の解説書『Pro Git』は、バージョン管理を「ファイルに加えられていく変更を記録して、あとで特定のバージョンを呼び出せるようにするしくみ」と説明しています。
難しく聞こえますが、やっていることはゲームのセーブとほとんど同じです。
| ゲームでいうと | Git では | やっていること |
|---|---|---|
| セーブする | コミット（commit） | いまのファイルの状態を、ひとことの説明つきで記録する |
| セーブデータの一覧 | ログ（log） | いつ、誰が、何のために変えたかを並べて見る |
| 前のセーブと比べる | 差分（diff） | どの行が増えて、どの行が消えたかを見る |
| ロードする | 戻す（revert など） | 前の状態に戻す |
| 別のセーブ枠で遊ぶ | ブランチ（branch） | 本番を残したまま、別の世界で試す |
大事なのは、セーブしたところまでしか戻れないことです。これもゲームと同じ。逆にいえば、こまめにセーブしてあれば、どんな失敗をしても、その手前に帰ってこられます。
ここで言うファイルは、プログラムに限りません。Web サイトの HTML や CSS、ゲームの設定、記事の原稿、画像も記録できます。『Pro Git』も、コンピューター上のほとんどどんなファイルでも使える、と書いています。
あの夜の8回を、読み返してみる
冒頭の8行は、それぞれのコミットにつけた「説明文」です。Git では、セーブするたびに「何を変えたか」をひとこと書きます。書いたのは、作業をした Claude Code です。私が「テレビっぽくしたい」「ボタンの位置が変」と頼み、Claude がファイルを書き換え、区切りのいいところでコミットしてくれていました。
9か月たったいま読み返すと、この説明文がそのまま日記になっています。
- 22時12分に、テレビ風のデザインに大きく変えた
- そこから25分ほど、ボタン・ヘッダー・マウスを乗せたときの動き（ホバー）を細かく直した
- 22時37分に電源ボタンを足し、43分に影と質感を足し、47分にアンテナを生やして、背を高くした
どのコミットも、変えた中身は小さめです。だからこそ、あとで「アンテナを足す前に戻したい」と思えば、22時43分のセーブに戻るだけで済みます。8回に分けずに、22時47分に1回だけセーブしていたら、アンテナだけを外すのは手作業になります。
セーブは細かいほど、戻すときにやさしい。
ちなみにこのテレビ、翌日には CSS で描いたものから本物のテレビの写真に差し替わり、9か月後には紙のノートに生まれ変わっています。アンテナは、もうありません。
この「細かく区切る」は、AI と作るときほど効きます。AI は一度に大量のファイルを書き換えられます。人が一つずつ手で直すときより、1回の変更が大きくなりがちです。変更が大きいほど、どこで何が壊れたのかを探すのが大変になります。
説明文は、未来の自分への手紙
同じ夜の、4分違いの2つの説明文を並べてみます。
22:29 ホバーエフェクト修正 22:33 Fix project card hover effect - replace ::after shadow with box-shadow
どちらも「マウスを乗せたときの動きを直した」コミットです。でも、9か月後に役に立つのは2つ目です。どこを（作品のカードの）、どう直したか（影の付け方を別の書き方に替えた）まで書いてあるので、同じ不具合がまた出たときに、何を試したかがすぐ分かります。1つ目は「何かを直した」ことしか分かりません。
ほかにも、このサイトの履歴には、あとから読んで助かる説明文がいくつもあります。
Rename news photos and update slideshow to 8 images：写真の名前を変えて、スライドショーを8枚にした。枚数まで書いてあるAdjust BGM/Voice ratio to 7:3 (35%/15%)：BGM と声の音量の比を7対3にした。実際の数字まで残っているRevert mobile layout changes - keep for later：スマホ向けの変更を戻した。理由は「あとでやる」（この話は少しあとで）
説明文に正解の書き方はありませんが、「何を」「どう」「なぜ」のうち2つ入っていれば、だいたい未来の自分は困りません。AI にコミットを任せるなら、「説明文には何をどう変えたかを書いて」と一言そえるだけで、履歴の読みやすさがかなり変わります。
4分で戻した日
セーブのありがたさを一番感じたのは、2026年8月22日です。舞台は、いま作っている落下ゲーム「Fall in Love」。中身はまだ公開前なので、舞台裏だけ書きます。
このときの Fall in Love は、二つの AI で分業していました。Claude と、OpenAI の Codex です。その日、ゲームの中の「森」の場面を、Codex がまるごと作り直すことになりました。
Fall in Love の履歴は、こう始まっています。
chore: preserve pre-redesign prototype。作り直す前の試作を、そのまま保存する。これが Fall in Love の最初のコミット。2,828個のファイル、7万7千行あまりを一度に記録したfeat: rebuild forest as a split sacred tree。Codex が森を作り直した。11個のファイルで、786行を足して902行を消しているRevert "feat: rebuild forest as a split sacred tree"。4分後、作り直しをコミットごと取り消した- 失敗の分析を文書にして残す
20時11分に残した文書には、こう書かれています。
Codexが行った森v2はユーザーから「あまりにもひどい」と明確に不採用になり、コミットごとrevert済み。
「あまりにもひどい」は、私が言った言葉です。記録に残ってしまっています。
ここで注目してほしいのは、取り消すのにかかった時間です。786行を足して902行を消した変更が、1回のコマンドで元に戻っています。11個のファイルを覚えておいて、一つずつ手で直したわけではありません。作り直す直前の19時43分に「保存」のコミットがあったからできたことです。
同じ文書の最後には、次からの進め方として、こんな一文も残っています。
一層全部を作ってから見せない。戻す単位を小さくする。
先ほどの「セーブは細かいほどやさしい」と同じ話です。森の作り直しは、絵の方向を確かめないまま、場面全体と材質と3D モデルまでを一度に作っていました。戻せたから被害はゼロでしたが、4分で捨てた作業は、その前の何十分ぶんかです。小さく作って、見せて、良ければ次へ。そうしていれば、捨てる量も小さくて済みました。
「戻す」には2種類ある
Git で前の状態に戻す方法は、いくつかあります。初心者がまず知っておけばいいのは、この2つの違いです。
| revert（リバート） | reset（リセット） | |
|---|---|---|
| やること | 「取り消し」という新しいコミットを足す | 履歴そのものを巻き戻す |
| 失敗した変更の記録 | 残る（あとで見返せる） | 消える |
| 向いている場面 | 一度セーブした変更を取り消すとき全般 | まだ誰にも渡していない、手元だけの変更を捨てるとき |
公式の説明では、revert は「すでにあるコミットが持ち込んだ変更を取り消して、そのことを新しいコミットとして記録する」ものです。Fall in Love で使ったのも revert でした。だから、失敗した森も、取り消したことも、両方が履歴に残っています。失敗の分析を書けたのは、失敗そのものが消えていなかったからです。
reset は強力なぶん、使い方を間違えると、セーブしていない作業ごと消えます。迷ったら revert、と覚えておけば大きな事故はしません。
「あとでやる」のための戻し方
戻す理由は、失敗だけではありません。このサイトの2026年2月7日の夜中の履歴です。
- スマホでの表示崩れと、BGM と声が重なる問題を直す
- スマホでは、テレビ全体を縮めて画面に収め、ボタンを下に置く
Revert mobile layout changes - keep for later。スマホ向けの変更を戻す。あとでやる- YouTube Shooting の紹介アニメを作り直す
スマホ向けの直しを途中まで進めて、いったん戻しています。説明文は「keep for later（あとでやる）」。そして実際に、スマホ向けのレイアウトが入ったのは、6週間後の3月19日でした。
このとき戻した変更は、消えたわけではありません。履歴の中に「途中まで進めたスマホ版」として残っています。手を付けたけれど今はやめておく、という判断が、作業を捨てずにできる。これも Git の良いところです。
ブランチ：本番を触らずに、別の世界で試す
ここまでのセーブは、一本道でした。ブランチは、その道を途中で枝分かれさせる仕組みです。ゲームでいえば、セーブ枠を分けて「本編はそのまま、別の枠でちょっと無茶をしてみる」感じです。
このサイトでは、2026年10月22日の作り直しで、ブランチを使いました。
- main：本番のブランチ。ここに変更を送ると、約30秒で usuilab.com に出る
- notebook-articles：記事を書き直すための作業ブランチ。ここに送ると、確認用の別の URL にだけ出る
朝6時47分から10時51分まで、記事の書き直しはずっと作業ブランチで進めました。本番の usuilab.com は、その間ずっと前のままです。書き直したものを確認用の URL で見て、11時3分に main へ合流（マージ）させて、初めて本番に出ました。
途中で、急いで本番に出したい変更が一つだけありました。YouTube Shooting のコードの置き場所を非公開にしたので、サイトからそこへのリンクを外したかったんです。リンク切れのまま何時間も待たせたくない。そこで、その1つの変更だけを先に main へ入れました（図の点線）。書きかけの記事は作業ブランチに置いたまま、です。
このノートも、いまこの瞬間、同じ作業ブランチで書いています。あなたが本番で読んでいるということは、確認用の URL で見て OK が出て、合流したということです。
ブランチを使っていなかった頃は、1月のテレビの8回も含めて、全部を main に直接セーブしていました。当時は GitHub Pages が main をそのまま公開する作りだったので、送ったものはすぐ本番です。アンテナが生えていく途中も、送っていれば世界に出ていたことになります。
「並行作業の前に git init」という決まり
Fall in Love の作業ルールを書いたファイル（AI が作業の前に読む決まりごと）には、分業の章に、こんな一行があります。
並行作業の前に git init。バージョン管理なしで2つのエージェントを走らせない
git init は、そのフォルダで Git を使い始めるコマンドです。「エージェント」は、ここでは Claude や Codex のように、自分でファイルを書き換えていく AI のこと。2つの AI に同じゲームを同時に触らせるなら、その前に必ずセーブの仕組みを用意しておく、という決まりです。
実は、さっきの「4分で戻した日」の最初のコミットが、まさにこれでした。Fall in Love の Git の記録は、8月22日19時43分の「作り直す前の試作を保存」から始まっています。それより前の作業は、Git の外にありました。Codex に大きな作り直しを任せる、その直前に Git を始めて、まず全部をセーブした。だから4分後に戻せたわけです。
2つの AI が同じフォルダで同時に動くと、こんなことが起きえます。
- 片方が書き換えたファイルを、もう片方が古い内容で上書きする
- どちらの変更で壊れたのか分からなくなる
- 壊れる前の状態に戻そうにも、戻る先がない
Git があれば、少なくとも3つ目は防げます。さらにこのルールでは「同じファイルを両方が触らない」とも決めていて、Claude はゲームの中身、Codex は音と演出や 3D モデルづくり、と持ち場を分けていました。セーブの仕組みと、持ち場の線引き。AI を2人雇うなら、この2つがセットです。
セーブしていなかった話
ここまで偉そうに書いてきましたが、正直に書いておきます。
このノートを書くために Fall in Love の履歴を数えたら、コミットは全部で6回でした。8月25日を最後に、コミットが止まっています。一方で、まだセーブしていない変更が、661件（ファイルやフォルダの単位で）たまっていました。
ゲームの作業は、その後も10月まで続いています。新しい場面も、予告編も作りました。でも、そのほとんどが、まだ Git のセーブに入っていません。いまパソコンが壊れたり、AI が大事なファイルを消したりしたら、8月25日まで巻き戻るしかない、ということです。
セーブポイントは、作っただけでは守ってくれない。
Git は自動ではセーブしてくれません。「ここで区切る」と決めてコミットしないかぎり、記録は増えません。このサイトの152回は、Claude Code が区切りごとにコミットしてくれていたから増えた数字です。Fall in Love では、その習慣が途中で止まっていました。人に「まずセーブ」と言う前に、自分のフォルダを見たほうがいい、という例です。
最低限のコマンド5つ
Git のコマンドはたくさんありますが、一人で始めるなら、これだけで十分です。<と>で囲んだところは、自分の内容に置き換えてください。
git init ← このフォルダで Git を始める（最初の1回だけ） git add . ← 今の変更を、次のセーブに入れる準備をする git commit -m "<何を変えたか>" ← セーブする。説明文をひとこと添える git log --oneline ← セーブの一覧を1行ずつ見る git revert <コミットの番号> ← そのセーブの変更を取り消す（取り消しもセーブとして残る）
ブランチを使うなら、もう一つだけ。
git switch -c <ブランチの名前> ← 新しいブランチを作って、そちらへ移る
コミットの番号は、git log --oneline の行の先頭に出てくる7文字ほどの英数字です（例：Fall in Love の作り直しは 443ce89）。
Windows に入れる
Git の公式サイトの Windows 向けページから、インストーラーを落として入れるのがいちばん確実です。2026年10月22日に確かめたときの最新は 2.56.0 で、10月5日に出たものでした。
Windows のパッケージ管理（winget）を使うなら、PowerShell で次の1行でも入ります。
winget install --id Git.Git -e --source winget
ただし公式ページには、winget の Git.Git は Git for Windows のプロジェクト自身が管理しているものではなく、最新版から遅れることがある、という注意書きがあります。迷ったら公式のインストーラーにしておきましょう。
入ったかどうかは、PowerShell で git --version と打って、バージョンの番号が出れば OK です。
AI と使うなら、コマンドより「頼み方」
正直に言うと、私は上のコマンドを毎日自分で打っているわけではありません。このサイトの152回のコミットのうち85回には、共同作業者として Claude の名前が記録されています。実際にコマンドを打っているのは、ほとんど Claude Code です。
それでも Git の考え方を知っておく意味は大きいです。何を頼めばいいかが分かるからです。たとえば、こういう頼み方ができます。
これから森の場面を大きく作り直してもらいます。 その前に、今の状態を「作り直す前の保存」としてコミットしてください。 作り直しは、場面全体ではなく最初の一区画だけにして、 画面の画像を見せてから続きに進んでください。
さっきの作り直しは採用しません。 revert で取り消して、取り消したことも履歴に残してください。 そのあと、なぜ不採用になったかを docs/ に短くまとめてください。
本番の main は触らずに、新しいブランチを作って、そこで作業してください。 終わったら確認用の URL を教えてください。私が見て OK を出したら main に合流させます。
どれも、このノートに出てきた実際の出来事を、頼み方の形にしたものです。「セーブしてから始めて」「戻して」「別の枠でやって」。この3つが言えれば、AI との開発はかなり安心になります。
このノートから持ち帰れること
Git に限らず、「あとで戻れるようにしておく」は、作るもの全般に効く考え方です。
- 大きく変える前に、まずセーブFall in Love の森は、作り直す直前の「保存」があったから4分で戻せた。AI に大仕事を任せる前、自分で大きく変える前に、今の状態を残す。サイトのデザイン変更、ゲームの作り直し、Excel や原稿の大幅な書き換え
- セーブは細かく、説明文はひとことでも35分で8回に分けてあれば、アンテナだけを外せる。説明文は9か月後の自分への日記になる。毎日の作業の区切り、AI に作業を頼むとき
- 迷ったら「消す」より「取り消しを記録する」revert なら、失敗も取り消しも両方残る。失敗の分析は、失敗が残っているから書ける。不採用になった案、ボツにした原稿、試して戻した設定
- 本番の横に、試す場所を作る作業ブランチと確認用の URL があれば、本番を止めずに直せる。急ぎの1つだけ先に出す、もできる。公開中のサイト、配布中のアプリ、共有している資料
- AI を2人使うなら、セーブの仕組みと持ち場の線引きをセットで同じフォルダを同時に触らせる前に git init。同じファイルは片方だけが触る。Claude と Codex の分業、人と AI の共同作業
- 今作っているもののフォルダで、Git が始まっているか（
git statusがエラーにならないか） - 最後にコミットしたのはいつか。まだセーブしていない変更が山になっていないか
- AI に大きな作業を頼む前に、「先にコミットして」と言っているか
- 公開中のものを直すとき、本番とは別の試す場所があるか
やってみよう
記事と同じことを、手元の AI で試せる指示文です。ChatGPT・Gemini・Claude のどれでも使えます。AI は毎回ちがう答えを返すので、記事とまったく同じ条件にはなりませんが、考え方の練習にはしっかり使えます。実際にやってみてください。
練習1自分の作業を「セーブの単位」に分ける
私はこれから、次の作業をします。 （例：自分のサイトのトップページを、ブラウン管テレビ風のデザインに変える） この作業を、Git のコミットの単位に分けてください。 1つのコミットは「あとでそこだけ取り消したくなるかもしれない、ひとまとまり」にしてください。 それぞれに、コミットの説明文（日本語でひとこと）もつけてください。
分け方が細かすぎず、粗すぎないか。「ここだけ戻したい」が起きそうなところで区切られているか。
練習2revert と reset のどちらを使うか、判断させる
Git で、次の場面ではどの戻し方を使うべきか、理由といっしょに教えてください。 初心者にも分かる言葉でお願いします。 1. 2時間前にコミットして、もう GitHub にも送った変更を取り消したい 2. 5分前に書き換えたけど、まだコミットしていない変更を捨てたい 3. AI が作り直した変更を取り消したいが、何がダメだったかは記録に残したい
3番に revert が出てくるか。reset を勧めるとき、何が消えるかの注意があるか。
練習3AI に大仕事を頼む前の「ひとこと」を作る
AI のコーディング道具（Claude Code など）に、プロジェクトの大きな作り直しを頼みます。 （例：ゲームの森の場面を、まるごと作り直してもらう） 失敗しても簡単に戻せるように、作業を始める前に AI に伝えておくべき指示を、 箇条書きで5つ考えてください。Git のコミットやブランチの使い方を含めてください。
「始める前にコミット」「小さく作って見せる」「別のブランチで」が入っているか。記事の Fall in Love の森と比べてみる。
出典・参考にした情報
- Pro Git（日本語版）「1.1 使い始める - バージョン管理に関して」
- Git 公式リファレンス「git-revert」（英語）
- Git 公式サイト「Install for Windows」（版 2.56.0、2026年10月5日公開。winget の注意書き、英語）
- コミットの時刻と説明文は、このサイト（usuilab）と Fall in Love の Git の履歴から。Fall in Love の作業ルールと失敗の分析は、同じリポジトリの文書から
いずれも 2026年10月22日に確認しました。下書きや図づくりには AI を使っていますが、事実関係は自分で確かめてから公開しています。
ウスイ福岡で個人開発をしています。アプリやゲームを作りながら、分かったことをこのノートに書いています。運営者・編集方針