AIにコードを書かせる前のGit準備：作業ブランチと小さなコミットの切り方

作業開始前の手順書

次の順に進めます。所要時間は数分です。

1. Git のバージョンを確認する:git --version。git switch は Git 2.23.0 で追加されたコマンドなので、それより古い場合は git checkout -b で代用します。
2. 未コミットの変更がないか見る:git status。変更が残っていると、AIの変更と自分の変更が混ざり、後で分けられなくなります。残っているなら先にコミットするか、git stash で退避します。
3. 土台にするブランチを決める:たとえば main。リモートがあるなら最新の状態にしてから進めます。
4. 作業ブランチを切る:git switch -c ai/due-date main。git switch の公式ドキュメントにあるとおり、-c は新しいブランチを作って切り替えるオプションで、末尾に開始地点(start-point)を指定できます。開始地点を書いておくと、いまどこにいてもその地点から分岐できます。
5. 基準を記録する:テストや起動コマンドを先に実行し、「すべて通る」か「元から3件失敗している」かをメモします。これがないと、AIが壊したのか最初から壊れていたのか区別できません。
6. AIに範囲を伝える:次節の依頼文を使います。

ブランチ名は ai/ のような接頭辞に目的を添えると、後で一覧したときに判別しやすくなります。これは編集上の提案で、Git の決まりではありません。

AIに渡す依頼文

ブランチを切ったら、AIには目的・触ってよい範囲・やらないことを最初に渡します。コピーして括弧内を差し替えてください。

【目的】(例:ToDo一覧に期限日を YYYY-MM-DD 形式で表示する)
【触ってよいファイル】(例:src/todo.js, src/format.js, test/todo.test.js)
【やらないこと】
- 上記以外のファイルの変更
- 目的と関係のない整形・変数名変更・リファクタリング
- 依存パッケージの追加や更新(必要なら理由を書いて私に確認する)
- git commit や git push の実行(コミットは私が行います)
【現状】テストは `npm test` で、いま全件通ります。(基準を記録した結果を書く)
【完了条件】`npm test` が通ること。変更したファイルと理由を最後に箇条書きで報告する。

「コミットは私が行う」にしておくのは、区切りを人が決めるためです。AIに自動でコミットさせる運用もありますが、1回の作業で複数の目的が混ざったまま1コミットになりやすいので、慣れるまでは人が切るほうが安全です(提案です)。

それでも依頼文の範囲外の変更が混ざることはあります。次の節がその対処です。

1つの目的ごとにコミットを分ける具体例

以下は説明用の例です。AIが依頼を終えて git status を見ると、次のように変更されていたとします。

• src/format.js、変更内容：日付を整形する関数を追加、目的：A:期限表示(依頼の本題)
• src/todo.js、変更内容：期限表示で上の関数を呼ぶ、目的：A
• src/todo.js、変更内容：無関係な変数名を t から task に変更、目的：B:整理(依頼外)
• test/todo.test.js、変更内容：期限表示のテストを追加、目的：A
• package.json、変更内容：日付ライブラリを依存に追加、目的：C:依存追加(依頼外)

目的がA・B・Cの3つ混ざっています。1コミットにまとめると、後で「変数名の変更だけ戻したい」「ライブラリ追加だけ戻したい」と思っても切り分けられません。

git add -p で変更の一部だけを選ぶ

git add の公式ドキュメントによると、git add -p(--patch)は変更の塊(ハンク)ごとに、ステージするかどうかを対話的に選べます。主な入力は次のとおりです。

• y:このハンクをステージする
• n:ステージしない
• s:ハンクをより小さく分割する
• e:ハンクを手で編集する
• q:終了する

変数名の変更と期限表示が近い行にあると、1つのハンクに混ざります。その場合は s で分割し、それでも分かれなければ e で編集します。

実際の流れ

# 1コミット目:期限表示(目的A)だけを選ぶ
git add -p src/todo.js        # 期限表示のハンクに y、変数名変更のハンクに n
git add src/format.js test/todo.test.js
git diff --cached             # ステージ済みの内容に目的A以外がないか確認
npm test
git commit -m "feat: ToDoの期限日をYYYY-MM-DD形式で表示する"

# 2コミット目:変数名の整理(目的B)
git add src/todo.js
npm test
git commit -m "refactor: todo.jsの変数名を整理する"

# 依存追加(目的C)は、本当に必要か人が判断してから別コミットにする

ポイントは git diff --cached です。コミットする前に、ステージ済みの差分がその1目的だけになっているかを自分の目で確認します。この確認はAIに任せず、人が行ってください。

小さなコミットの目安

次の点を満たしているかで判断します。数値の基準はなく、編集上の目安です。

• メッセージを「〜と〜」でつながず、一文で言い切れる
• その時点でテストが通る(後で原因の範囲を絞るときに、途中のコミットが壊れていると使えません)
• 差分を人が最後まで読める量に収まっている
• 機能とそのテストは同じコミットに入れる

取り消しの判断表

AIの変更がうまくいかなかったとき、どこまで進んだかで手段が変わります。

• まだコミットしていない変更を全部諦める、取る手段：先に git stash か仮コミットで退避してから戻す、注意：未コミットの変更は、破棄すると Git の履歴から戻せないことがあります
• 作業ブランチ全体が不要になった、取る手段：main に戻り、作業ブランチを削除する、注意：未コミットの変更が残っていないことを確認してから削除します
• 一部のコミットだけ不要。自分のブランチ内、取る手段：該当コミットを git revert で打ち消す、注意：履歴が残り、あとから確認できます
• すでに共有(push)した、取る手段：git revert を使う、注意：共有済みの履歴を書き換えると、他の人の作業とずれます

git revert は、公式ドキュメントでは既存コミットの変更を打ち消す新しいコミットを作るコマンドと説明されています。元のコミットを消すわけではありません。実行時は作業ツリーがきれいな状態である必要があるため、先に未コミットの変更を片づけておきます。複数のコミットをまとめて打ち消してひとつにしたいときは git revert -n を使います。-n(--no-commit)を付けると、打ち消した結果が作業ツリーとインデックスに反映されるだけでコミットは作られず、内容を確認してから自分でコミットできます。たとえば git revert -n A..B のように範囲を指定できます。

マージコミットを打ち消す場合は、どちらの親を本流とみなすかを -m で指定する必要があります。この場合は公式ドキュメントを読みながら慎重に進めてください。

作業中に守る運用ルール

最後に、手順書へ足しておくと効くルールを三つ挙げます。いずれも編集上の提案です。

1. AIへの次の依頼の前にコミットする:前の変更が未コミットのまま次を頼むと、どの変更がどの依頼によるものか分からなくなります。
2. 想定外のファイルが変わっていたら、まず git status で一覧を見る:依頼文に書いた範囲外のファイルは、理由を確認するまでステージしません。
3. 完了したらブランチを main に取り込む前に、コミット一覧を見直す:git log --oneline main..ai/due-date で、目的ごとに並んでいるかを確認できます。

作業前にブランチを切って基準を記録しておく数分のおかげで、AIの変更は「いつでも戻せる単位」に分かれた状態で手元に届きます。