Claude Code Academia

第8章 Git と GitHub — 履歴管理が一瞬で済むようになる

第2章の「世界地図」で軽く触れた、Git と GitHub。「図書館」の比喩で紹介しましたが、ここで本格的に向き合います。

僕が「git push 一本で更新も履歴管理もできるのがめっちゃ便利」と実感している、その感覚を体験してもらう章です。

第8章のゴールは2つ。

  1. Git / GitHub の役割と仕組みを「比喩」レベルで理解する
  2. Code に push してもらうだけで、自分のコードに完璧な履歴管理が付く状態を作る

コマンドの細かい話は出てきません。すべて Code に任せます。

8-1. なぜ Git が必要なのか — 履歴管理という安心感

【学習目標】

  • Git があると何が嬉しいのかを実感ベースで理解する
  • 「ファイルを上書きし続ける」やり方のリスクを知る

【前提知識】

  • 第7章まで完了していること

【概念解説】

Git なしで Web 制作をする世界を想像してみてください。

1. index.html を作る → 完成！
2. ある日「やっぱりここ変えよう」と上書き保存
3. 数日後「あ、前のやつの方が良かったかも…」
4. でも、前のバージョンはもう存在しない
5. 記憶を頼りに書き直す（しかし完全には思い出せない）

これ、めっちゃ怖くないですか？でも、Git を知らない頃の Web 制作は、基本的にこんな感じだったんです。

Git が解決する問題

Git は、ファイルの全履歴を時系列で保存してくれます。

1. index.html を作る → 「最初の版」として記録
2. ある日「やっぱりここ変えよう」 → 「2版目」として記録（最初の版も残ってる）
3. 数日後「やっぱり最初に戻したい」 → 簡単に戻せる
4. 戻したけど、2版目も消えてない → いつでも復元可能

つまり、「上書き保存」が「履歴を積む」に変わるんです。これがどれだけの安心感をもたらすか、Git を一度使ったら戻れません。

僕の実体験

僕は Git なしで Web 制作をしていた頃、毎回バックアップを手動でとっていました。

index.html
index_20120415.html   ← 何のバックアップ？
index_old.html        ← old って何時点の？
index_new.html        ← え、これと現在版どっちが新しい？

これ、心当たりがある人多いんじゃないでしょうか。Git を使うと、こういう「自前バックアップの戦争」から解放されます。

もうひとつのメリット：実験できる

Git があると、「ちょっと大胆に書き換えてみよう」が怖くなくなります。最悪、Git で前のバージョンに戻せばいい。実験するハードルが劇的に下がる。

これは創造性に直結します。「壊したら元に戻せない」プレッシャーがあると、無難な選択しかできない。「壊しても戻せる」と分かっていると、思い切った挑戦ができる。

「でも、コマンド覚えるんでしょ？」への回答

ここがこの章で一番伝えたいこと。Git のコマンドは1個も覚えなくていいんです。

なぜなら、Code に「変更を保存して、GitHub に上げといて」と言うだけで、Git の操作は全部やってくれるから。あなたがやることは、

  • Code に依頼する
  • 結果を確認する

それだけ。Git はあなたの背後で静かに、完璧に履歴を管理してくれます。

【ハンズオン手順】

▼ ブラウザ側でやること（Git のイメージを掴む）

  1. ブラウザに次のように打ってみる
Git を「自前バックアップの戦争」から解放してくれるもの、
として説明しました。これを別の比喩で説明するなら、
どんな比喩がありますか？3つ提案してください。
  1. ブラウザが答える（「タイムマシン」「セーブポイント」「演劇のリハーサル記録」など）
  2. 自分にしっくりくる比喩を選ぶ

【つまずきポイント】

  • 「Git を学ばないと使えない」は誤解。Code 経由で使うなら、コマンドは1個も覚えなくてOK
  • Git の知識をネットで調べると、いきなり難しい話が出てくる。それは「自分でコマンドを叩く前提」の話なので、本書では無視

【確認問題】

  • Git がない時代に、人々が手動でやっていた「自前バックアップ」のリスクは何ですか？
  • Git を使うと、心理的にどう変わりますか？

【次のレッスンへの橋渡し】

Git の価値が分かりました。次は、Git と GitHub の違いを、もう一度ちゃんと整理します。

8-2. Git と GitHub の違いと全体図

【学習目標】

  • Git と GitHub が別物だと改めて理解する
  • 自分のPC、Git、GitHub の3者の関係を図でイメージできる

【前提知識】

  • 8-1 で Git の必要性を理解していること
  • 2-5 で「Git は仕組み、GitHub は場所」と聞いていること

【概念解説】

繰り返しになりますが、改めて整理します。

Git は「履歴管理の仕組み」

  • 自分のPC内で動く
  • ファイルの変更履歴を時系列で記録する
  • 過去のバージョンに戻れる
  • ローカル（自分のPC）で完結する

GitHub は「Git のクラウド倉庫」

  • インターネット上にあるサービス
  • 自分のPCの Git の履歴を、ここにバックアップする
  • 他人と共有できる
  • Microsoft が運営している

3者の関係を図にすると

[あなたのPC]
   ├── index.html などのファイル
   └── .git/   ← Git の履歴データ（隠しフォルダ）
                 ローカルで全履歴を持っている
        ↓ git push
[GitHub]
   └── インターネット上のクラウド倉庫
        ローカルの履歴のバックアップ

「3つの場所」がある

ちょっと混乱しがちなので、3つの「場所」を整理しておきます。

1. 作業ディレクトリ（あなたが普段触っているファイル）

  • index.html、style.css、script.js などの実際のファイル
  • 普通に Finder やエクスプローラーで見えるやつ

2. ローカルの Git リポジトリ（自分のPC内、隠れている）

  • .git という隠しフォルダの中
  • ファイルの全履歴が圧縮されて保存されている
  • 普通は見えないし、見る必要もない

3. GitHub のリポジトリ（インターネット上）

  • 自分のローカル Git の内容をクラウドにバックアップしたもの
  • ブラウザで閲覧できる
  • 他人にも見せられる

「ローカル Git を GitHub に上げる」のが、git push と呼ばれる操作です。

じゃあ、何でわざわざ GitHub に上げるの？

理由は3つ。

  1. バックアップ：自分のPCが壊れても、GitHub にあれば復元できる
  2. 共有：他のPC（他人含む）から同じプロジェクトにアクセスできる
  3. デプロイ連携：Cloudflare Pages などのホスティングが GitHub を見て自動デプロイする（第10章）

特に3つ目が、僕が感動した「git push 一本で公開まで終わる」体験につながります。

【ハンズオン手順】

▼ ブラウザ側でやること

  1. ブラウザに次のように打って、自分の理解を確かめる
Git と GitHub の違い、そして「作業ディレクトリ」「ローカル Git」
「GitHub のリポジトリ」の3者の関係を、初心者にも分かるように
比喩で説明してください。
  1. 自分の理解とブラウザの説明を照らし合わせる

▼ Code 側でやること（既存プロジェクトを確認する）

  1. 第1章で作ったプロジェクトフォルダを Code で開く
  2. Code に次のように聞く
今このプロジェクトは Git で履歴管理されていますか？
GitHub には繋がっていますか？
  1. Code が状態を答える（まだ Git 未設定の可能性が高い）

【つまずきポイント】

  • 「Git と GitHub は同じものでしょ？」と思わない。別物です
  • 「リポジトリ」という言葉が出てくるが、これは「Git で管理しているフォルダ全体」のこと。難しく考えず「プロジェクトフォルダ」と同じ意味と思えばOK
  • .git フォルダを自分で開いたり編集したりしない。中身を触ると Git が壊れます

【確認問題】

  • Git と GitHub の違いを一文で説明してください
  • ローカル Git の履歴を GitHub にアップロードする操作を、英語で何と言いますか？

【次のレッスンへの橋渡し】

理屈は見えました。実際にやってみましょう。次は GitHub アカウントを作るところから。

8-3. GitHub アカウントを作る — ブラウザに手順を聞きながら

【学習目標】

  • GitHub アカウントを作成できる
  • 「リポジトリ」を作成する流れを把握する

【前提知識】

  • 8-2 まで読んでいること

【概念解説】

GitHub を使うには、まずアカウントが必要です。無料です。

「えっ、Microsoft のサービスなのに無料？」と思うかもしれませんが、基本的な機能は全部無料で使えます。有料プランは、企業や上級者向け。個人で趣味のアプリを作る分には、無料プランで充分。

アカウント作成の全体像

1. github.com にアクセス
2. Sign up（新規登録）をクリック
3. メールアドレス・パスワード・ユーザー名を設定
4. メール認証
5. アンケート（スキップ可）
6. プラン選択（無料を選ぶ）
7. 完了

これだけ。所要時間は5分くらい。

設定するもの

3つ決めるだけ。

  1. メールアドレス

    • 普段使っているもので OK
    • Claude のアカウントと同じでも違っても、どちらでも

  2. ユーザー名

    • 公開される名前。プロフィール URL の一部になる
    • 例：UzAvie → https://github.com/UzAvie
    • 後から変えるのは面倒なので、ちょっと考えてから決める

  3. パスワード

    • 強めに設定
    • パスワードマネージャーで保存推奨

リポジトリとは

GitHub アカウントを作ったら、次に「リポジトリ」を作ります。

リポジトリとは「1つのプロジェクトの保管場所」です。1プロジェクト＝1リポジトリ。

たとえば：

  • カフェ紹介サイト → cafe-site リポジトリ
  • 訪看時間管理アプリ → homebisit-app リポジトリ
  • 個人ブログ → my-blog リポジトリ

それぞれ別のリポジトリとして管理します。

リポジトリには「Public（公開）」と「Private（非公開）」があります。

  • Public：誰でもコードを閲覧できる
  • Private：自分（とアクセス権を与えた人）だけ閲覧できる

初心者は Private にしておくのが安全です。間違って機密情報を上げても、外部に漏れません。

【ハンズオン手順】

▼ ブラウザ側でやること（アカウント作成）

  1. ブラウザで https://github.com にアクセス
  2. 「Sign up」をクリック
  3. 画面の指示に従って、メール・パスワード・ユーザー名を設定
  4. メール認証を完了
  5. プラン選択画面で「Free」を選ぶ
  6. アカウント作成完了

▼ ブラウザ側でやること（リポジトリ作成）

  1. ログイン後、画面右上の「+」アイコン → 「New repository」をクリック
  2. リポジトリ名を入力（例：cafe-site-test）
  3. 「Private」を選択
  4. 「Initialize this repository with a README」のチェックは外しておく（後で Code が作ります）
  5. 「Create repository」をクリック
  6. 作成完了画面で、リポジトリの URL が表示される（メモしておく）

▼ ブラウザ側で困ったら

  • 「GitHub の Sign up でエラーが出ました（スクショ）」など、画面のスクショを貼ってブラウザで対処

▼ スクショ伴走のチェックポイント

  • アカウント作成完了の画面
  • 作成したリポジトリの画面（リポジトリ URL が見える状態）

【つまずきポイント】

  • ユーザー名は他人と被れない。希望の名前が取られていたら、別のを考える
  • メール認証を忘れると、リポジトリ作成ができない場合がある
  • Private を選び忘れると、世界中の誰でもコードが見える状態に。間違って API キーを上げると即漏洩。Private 推奨

【確認問題】

  • GitHub のリポジトリで、Public と Private の違いは何ですか？
  • 初心者はどちらを選ぶのが安全ですか？

【次のレッスンへの橋渡し】

GitHub アカウントとリポジトリができました。次は、自分のローカルファイルを GitHub に上げる「push」を Code にやってもらいます。

8-4. ローカル → GitHub への push を Code に任せる

【学習目標】

  • ローカルプロジェクトと GitHub リポジトリを連携できる
  • push の操作を Code に任せて、コードを GitHub に上げられる

【前提知識】

  • 8-3 で GitHub アカウントとリポジトリを作っていること

【概念解説】

ここまでで、

  • 自分のPCにプロジェクトフォルダがある（第1章で作ったやつ）
  • GitHub に空のリポジトリがある（8-3 で作ったやつ）

この2つを「繋ぐ」のが、次のステップ。繋ぐと、ローカルの変更を git push で GitHub に送れるようになります。

繋ぐ手順の全体像

1. ローカルフォルダで Git を初期化（`.git` フォルダを作る）
2. ローカルの GitHub リポジトリの URL を伝える
3. ファイルを「コミット」（Git の言葉で「履歴に記録」）
4. GitHub に push

これ、Code に丸投げできます。

Code への依頼の仕方

具体的にはこんな感じで依頼します。

このプロジェクトを GitHub にプッシュしたいです。
GitHub のリポジトリ URL は https://github.com/○○/cafe-site-test です。

次のことをやってください：
1. このフォルダで Git を初期化
2. 現在のファイル全てをコミット（コミットメッセージは「初回コミット」）
3. GitHub のリポジトリと連携
4. main ブランチに push

Code は順番にコマンドを実行して、各ステップで「これでいい？」と確認しながら進めてくれます。

初回 push の時にハマるポイント

初回 push には、GitHub への認証が必要です。

  • Personal Access Token（PAT）を作る
  • もしくは GitHub CLI（gh）で認証する
  • もしくは GitHub Desktop アプリを使う

これらの認証手順は、Code が画面に出してくれるので、その通りにやれば OK。困ったらスクショをブラウザに貼って「次は何すれば？」と聞きましょう。

2回目以降の push は超簡単

初回さえ通れば、2回目以降は次のように依頼するだけ。

最新の変更を GitHub にプッシュして。
コミットメッセージは「○○の修正」で。

Code が自動的に：

  1. 変更されたファイルを検出
  2. コミット作成
  3. push 実行

これで終わり。毎回コマンド1回も打たずに、GitHub に最新版が上がります。

僕の実感

僕が「Git に push してもらうだけで更新や履歴の管理も一瞬で出来るのがめっちゃ便利」と感激したのが、この体験。3週間で複数のアプリを作る間、Git コマンドを自分で打ったことは1回もないんです。

【ハンズオン手順】

▼ Code 側でやること（初回 push）

  1. 第1章で作ったプロジェクトフォルダを Code で開く
  2. Plan モードに切り替え（安全のため）
  3. 次のように依頼
このプロジェクトを GitHub にプッシュしたいです。
GitHub のリポジトリ URL：[8-3で作ったURL]

次の手順で進めてください：
1. このフォルダで Git を初期化
2. .gitignore を作って、機密情報を除外
3. 現在のファイルを「初回コミット」としてコミット
4. GitHub と連携
5. main ブランチに push
  1. Code が Plan を提示
  2. Plan を確認して OK を返す
  3. Code が順に実行（途中で認証画面が出ることがあるので、ブラウザに聞きながら対応）

▼ ブラウザ側でやること（認証に詰まったら）

  1. 認証画面のスクショをブラウザに貼る
  2. 「これに対してどう対応すれば？」と聞く
  3. ブラウザが手順を教えてくれる

▼ ブラウザ側で確認

  1. GitHub のリポジトリページをブラウザで開く
  2. さっきまで空だったリポジトリに、ファイルがアップロードされているはず
  3. 「Hello GitHub!」状態

▼ スクショ伴走のチェックポイント

  • Code が push を実行する Plan のスクショ
  • 認証画面が出た時のスクショ
  • 完了後の GitHub リポジトリの画面

【つまずきポイント】

  • 認証で詰まることが多い。Personal Access Token が必要だったり、SSH キーの設定が必要だったり。ブラウザに聞きながら丁寧に進める
  • .gitignore を作るのは大事。.env や node_modules を間違えて push すると、機密情報漏洩や、リポジトリ肥大化のリスク
  • コミットメッセージは何でも良いが、後で見て分かる表現を。「変更」だけだと後で困る

【確認問題】

  • GitHub に最新版をアップロードする操作を、何と呼びますか？
  • 機密情報を間違えて GitHub に上げないために必要なファイルは何ですか？

【次のレッスンへの橋渡し】

push ができました。次は、その「履歴」を実際に使うレッスンです。過去のバージョンに戻る、差分を見る、というやつ。

8-5. 履歴を Code またはブラウザで確認する — 過去のバージョンに戻る／差分を読む

【学習目標】

  • Git の履歴を見る方法を知る
  • 「過去のバージョンに戻す」操作を Code に頼める

【前提知識】

  • 8-4 で初回 push を経験していること

【概念解説】

Git の最大のメリットは「過去に戻れる」こと。これを実際にやってみます。

履歴の見方

履歴を見る方法は3つあります。

1. Code に頼んで履歴を出してもらう

このプロジェクトのこれまでのコミット履歴を、
日付付きで一覧表示してください。

Code が時系列で履歴を表示してくれる。

2. GitHub の Web 画面で見る

  • GitHub のリポジトリページに行く
  • 「Commits」タブをクリック
  • 全コミット履歴がブラウザで見られる

3. ファイルの差分を見る

  • 「何が変わったか」を行単位で見られる
  • Code に「○○のコミットで何が変わった？」と聞けば教えてくれる
  • GitHub の Web でも「Compare」機能で見られる

過去のバージョンに戻す

戻す方法も Code に頼めます。

1週間前のバージョンに戻したいです。
コミット履歴を見せてください。どのコミットに戻すか選びます。

Code が履歴を出してくれて、「このコミットに戻して」と指定すると、戻してくれます。

「戻す」の種類

実は「戻す」にも種類があります。

A. 一時的に過去のバージョンを見る（checkout）

  • 過去のコードを表示する
  • 元に戻る時は最新版に戻れる
  • 「ちょっと当時のコードを確認したい」時に使う

B. 過去のバージョンを最新版にする（reset / revert）

  • 過去のコードを「現在」として書き換える
  • 元に戻すには、別途操作が必要
  • 「あの時のバージョンに戻したい」時に使う

これらの違いは、Code に説明してもらえば理解できます。実際の操作も Code 任せでOK。

「ブランチ」という考え方（少し先の話）

Git には「ブランチ」という機能もあります。「枝分かれ」のような意味。

  • 今は main ブランチ1本で運用しています
  • 本格的になってきたら：新機能は別ブランチで開発 → テストOKなら main にマージ
  • 壊しても main は安全
  • 今の段階では不要ですが、複数人で開発したり、大きな機能を追加するときに使います

これも僕が訪看アプリで実感した話。ブランチを使えば、本番環境に影響を与えずに新機能を試せます。

【ハンズオン手順】

▼ Code 側でやること（履歴を見る）

  1. プロジェクトを Code で開く
  2. 次のように依頼
このプロジェクトのコミット履歴を、日付・コミットメッセージ付きで
一覧表示してください。
  1. Code が履歴を表示

▼ Code 側でやること（差分を見る）

  1. 次のように依頼
最新のコミットで何が変わったか、ファイル単位で教えてください。
  1. Code が差分を表示

▼ Code 側でやること（過去のバージョンに戻す練習）

  1. 何か小さな変更を加えて push しておく（例：見出しの色を変える）
  2. その後、次のように依頼
さっきのコミットで色を変える前の状態に戻したいです。
1つ前のコミットに戻してください。
  1. Code が手順を提示（Plan モード推奨）
  2. Plan を確認して OK
  3. Code が戻す操作を実行
  4. ファイルを確認すると、色が元に戻っているはず

▼ ブラウザ側でやること（GitHub で履歴を見る）

  1. ブラウザで自分のリポジトリページを開く
  2. 「Commits」タブをクリック
  3. 全履歴が表示される
  4. 各コミットをクリックすると、何が変わったかが見られる

▼ スクショ伴走のチェックポイント

  • Code が表示した履歴一覧のスクショ
  • 差分表示のスクショ
  • 過去のバージョンに戻った後のファイルの状態のスクショ

【つまずきポイント】

  • 「過去のバージョンに戻す」は強力だが、注意が必要。最新の変更が消えることがあるので、必ず Plan モードで進める
  • 戻したことを GitHub に反映するには、再度 push が必要。「戻す」だけだとローカルだけ
  • 複雑な戻し操作は、ブラウザで予習してから Code に依頼するのが安全

【確認問題】

  • Git の履歴を一覧表示する方法を3つ挙げてください
  • 「過去のバージョンを最新版として書き換える」と「過去のバージョンを一時的に見る」、それぞれを何と呼びますか？

【次のレッスンへの橋渡し】

第8章はこれで完了です。Git / GitHub の世界がだいぶ身近になったと思います。

次は第9章、サブエージェントと MCP の話に進みます。これも「使わなくても進める」けど、知っておくと選択肢が広がる、というタイプの内容です。

← 第7章
第9章 →