「最初のセーブ」を入れる：init / add / commit を Claude Code に頼む — AI時代のGit/GitHub

Claude Code に「東京の天気を取る最小スクリプトを作って」と頼みました。10秒ほどで tokyo-weather/ というフォルダができ、その中に fetch.ts package.json README.md が並んでいます。試しに npm run dev と打つと、ターミナルに今の東京の気温が出ます。動いた。

ここで多くの人が止まります。「動いたから、次の機能を頼もう」と先に進む人。Finder で tokyo-weather を右クリックして tokyo-weather copy を作っておく人。そして、Claude Code に「やっぱり華氏も出して」と次の依頼を投げる人。

3人とも、24時間後に同じ後悔をします。最初のセーブを入れていない、という後悔です。

この連載 #01 で「セーブが要る理由」と「Git はほぼ壊せない」という安全宣言をしました。今日はその続きで、人生最初のセーブを Claude Code に入れてもらうところまでをやります。コマンドは1行も覚えなくて構いません。

TL;DR

• AI にプロジェクトを作らせた直後が、人生最初のセーブを入れるタイミング
• Claude Code に頼むのは1行だけ：「このフォルダを Git で管理して。最初のセーブを入れて」
• Git は3つのエリアでファイルを動かす：部屋（作業中）→ 段ボール（積み込み中）→ トラック（出発済み）
• init / add / commit の3コマンドは、それぞれ「家を建てる」「段ボールに詰める」「トラックに積んで出す」に対応
• .git/refs/heads/main を VS Code で開くと、**ブランチが「コミット ID を1行だけ書いたテキストファイル」**だと体感できる

Claude Code が tokyo-weather/ を作った直後の状態

最初に押さえておきたい事実があります。Claude Code が作ったばかりのフォルダは、Git から見ればまだ何もない状態です。フォルダは存在するし、ファイルもある。けれど Git は「このフォルダを管理してください」と頼まれていないので、何も追跡していません。

Pro Git の Recording Changes 章にこう書いてあります（公式 https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository）。

Remember that each file in your working directory can be in one of two states: tracked or untracked.

作業ディレクトリ内のファイルは、追跡されている（tracked）か追跡されていない（untracked）か、どちらかの状態にあります。

Claude Code が作った直後の fetch.ts package.json README.md は全部 untracked（追跡されていない）です。この状態でフォルダを Finder で消したり、Claude Code が次の依頼でこのファイルを上書きしたりすると、戻りません。RPG でいえば「最初のセーブポイントを踏む前」です。

ここに最初のセーブを入れるところから、この記事を始めます。

AI に頼む1行で init / add / commit が一気に走る

結論から書きます。Claude Code（または Cursor の AI、もしくは普段使っている AI アシスタント）に対して、次の1行を投げます。

このフォルダを Git で管理して。最初のセーブを入れて。メッセージは「東京天気アプリの雛形を追加」で。

Claude Code が裏で何をしているか、その実体は3行のコマンドです。

git init
git add .
git commit -m "feat: 東京天気アプリの雛形を追加"

3行とも、いま中身を全部理解しなくて構いません。役割だけ並べます。

• git init = このフォルダで Git を有効にする。実行すると .git/ というサブフォルダがひっそりと作られます
• git add . = 部屋にあるファイルを「次のセーブに入れる候補」として段ボールに詰める
• git commit -m "..." = 段ボールごとトラックに積んで、履歴に残す。-m のあとは荷札に書く文言（コミットメッセージ）

「家を建てる」「段ボールに詰める」「トラックに積んで出発」、この3つで Git のセーブが完成します。

feat: で始めているのは Conventional Commits（コミットメッセージの書き方の規約。Linux カーネルや多くの OSS が採用しています）の作法で、これは次回 #03 良いコミットメッセージ（AI に書かせる Conventional Commits）で本格的に扱います。今日は「feat: は新機能を入れた合図」とだけ覚えておけば十分です。

なぜ「段ボール」が要るのか — 3エリアの正体

ここまでに3エリアという言葉を3回くらい使いました。この記事で覚えていただきたいのは、これだけです。Git は3つのエリアでファイルを動かしている、というイメージ。

flowchart LR A["部屋<br/>(作業ディレクトリ)<br/>いま編集中のファイル"] B["段ボール<br/>(ステージング)<br/>次のセーブに入れる候補"] C["トラック<br/>(リポジトリ .git/)<br/>履歴に残った過去のセーブ"] A -->|"git add"| B B -->|"git commit"| C

「部屋」が作業ディレクトリ（working directory）。Finder で見えているフォルダの中身そのものです。 「段ボール」が index（Git の公式マニュアルでの呼び名。別名 staging area／ステージング）。 「トラック」がリポジトリ（.git/ の中の objects/ という場所に過去のセーブが全部保管されています）。

ここでひとつ疑問が浮かびます。なぜ「段ボール」が要るのでしょうか？ 部屋の中身を直接トラックに積めばいいじゃないか、と。

答えはシンプルで、部屋の全部を毎回積みたいわけではないからです。fetch.ts だけ commit したい、README.md は書きかけだから今回は積まない、というような選択を1段挟みたい。段ボールはその「選り分けスペース」です。

git-add の公式マニュアル（https://git-scm.com/docs/git-add）にもこう書いてあります。

Add contents of new or changed files to the index. The “index” (also known as the “staging area”) is what you use to prepare the contents of the next commit.

新規または変更されたファイルの内容を index に追加します。「index」（別名「staging area」）は、次のコミットの内容を準備するために使う場所です。

「次のコミットの内容を準備する場所」。これが段ボールの正体です。

VS Code Source Control パネルで履歴を確認する

ターミナルを覚えていなくても、VS Code（または Cursor。以下は VS Code 前提で書きますが Cursor も画面構成は同じです）の左サイドバーにある Source Control（ソース管理）アイコンを開けば、今どのファイルが部屋にあって、どれが段ボールに入っているか、一目で分かります。

flowchart TD P["VS Code 左サイドバー<br/>Source Control パネル"] A["Changes<br/>(部屋にあって段ボール未投入)"] B["Staged Changes<br/>(段ボール = git add 済み)"] C["コミットメッセージ入力欄"] H["別タブで履歴ツリー<br/>(Git Graph 拡張など)"] P --> A P --> B P --> C P --> H A -->|"+ ボタンでステージ"| B B -->|"コミット ボタンで履歴へ"| H

各ファイルをクリックすると「変更前と変更後」が左右の diff として開きます。Claude Code に作業を任せた直後、Source Control パネルを開いて diff を眺める、これが「AI が何をしたか」を確認する一番ラクな導線です。Source Control パネルがあれば、git status や git diff のコマンドを暗記する必要はありません。

.git/refs/heads/main を VS Code で開いてみる

ここからが今日のハイライトです。Claude Code が git init した直後、tokyo-weather/.git/refs/heads/main というファイルが生まれています（正確には、最初のコミットが入った時点でこのファイルが作られます。git init 直後・commit 前の段階では、refs/heads/main というファイルそのものがまだ存在しません）。

VS Code でこのファイルを開いてください。.git/ フォルダは隠しフォルダ扱いなので、VS Code の設定で「Files: Exclude」から **/.git の行を外すか、Cmd+P（macOS）の Quick Open に .git/refs/heads/main と直接打ち込みます。

中身は、たった1行です。

3f9b4a2c8d6e1f077e2d9b1a4c5e6f0a2b3c4d5e

40桁の英数字。これだけ。

**この1行が「ブランチ main の正体」**です。難しい仕組みは何もない。Git は「main というブランチは、いまこのコミット（40桁の ID）を指しています」と書いた1行のテキストファイルを refs/heads/main に置いているだけです。

公式の git-init マニュアル（https://git-scm.com/docs/git-init）にもこう書いてあります。

This command creates an empty Git repository – basically a .git directory with subdirectories for objects, refs/heads, refs/tags, and template files.

このコマンドは空の Git リポジトリを作ります。実体は .git ディレクトリと、その中の objects refs/heads refs/tags といったサブディレクトリ、それにテンプレートファイル群です。

refs/heads/ の中の main というテキストファイル、それが現在のブランチの実体だ、ということです。

なぜ #02 でこの「.git/refs/heads/main を開いてみる」体感を入れているか。理由は、ブランチをこのあと #05 で説明するときに、まったく怖くなくなるからです。「ブランチを切る」「ブランチを切り替える」と聞くと初学者は身構えますが、その実体は「1行のテキストファイルを増やしたり、HEAD の指し先を切り替えたり」だけ。今日この1行を見ておけば、3週間後にブランチが出てきたときに「ああ、あれか」と笑えます。

罠：git add した後に編集して、再 add を忘れる

最後にひとつだけ罠を共有します。git-add の公式マニュアル（https://git-scm.com/docs/git-add）にこう書いてあります。

This command can be performed multiple times before a commit. It only adds the content of the specified file(s) at the time the add command is run; if you want subsequent changes included in the next commit, then you must run git add again to add the new content to the index.

このコマンドはコミット前に何度でも実行できます。git add を走らせたその瞬間のファイル内容だけを index に追加するので、その後に追加した変更を次のコミットに含めたいなら、git add をもう一度走らせて新しい内容を index に追加する必要があります。

要するに、git add で段ボールに詰めた後、もう一度部屋でそのファイルを編集したら、段ボール側は古いままということです。そのまま git commit を打つと、古い内容のほうがトラックに積まれます。

AI に作業を任せている最中も同じです。Claude Code に「これを段ボールに入れて」と頼んだ後、別の依頼で同じファイルを編集させたら、もう一度「段ボールに入れて」を頼む必要があります。

回避策はシンプルです。Claude Code に頼むときは「変更を全部段ボールに入れてからセーブして」と統一する。裏で AI が git add -A（--all の短縮形。新規・変更・削除のすべてを段ボールに反映するオプション）と git commit をセットで走らせるので、取りこぼしが起きにくくなります。

AI 指示 × Git 操作 対応表（#02 の3行）

#01 で約束したとおり、各回の末尾に対応表を1つずつ足していきます。今日の3行はこれです。

#01 の対応表（「セーブ」「戻す」「差分を見る」の3行）と合わせて、いま手元には6行の AI 指示があります。この6行で、Git の基本操作は8割以上カバーできます。残りは連載が進むたびに少しずつ足していきます。

まとめ

私は Git を覚える前、tokyo-weather/ を Finder で複製して tokyo-weather copy/ tokyo-weather copy 2/ を作っていた時代が長くありました。AI と作業するようになってから、その「Finder コピー方式」では追いつかないと身をもって痛感しています。Claude Code は1分で同じファイルを3回書き換えてくれるので、Finder コピーは2回目の依頼でもう破綻します。

最初のセーブを入れる、というのはただの儀式ではなくて、「ここから先は壊れても戻せる」という安全装置を入れる作業です。AI に依頼を投げ続けるための土台。今日入れた feat: 東京天気アプリの雛形を追加 という1行のセーブが、明日の自分を1回は救ってくれます。

次回 #03 良いコミットメッセージ — AI に書かせる Conventional Commits では、今日 feat: で始めた荷札の書き方を本格的に扱います。Claude Code に下書きさせて、人間が「なぜそれをやったか」を1行だけ補う分業の仕方を共有します。