AIコーディングを壊しにくくするGit入門

AIコーディングで壊れにくくする要点は、変更を小さく分け、mainブランチ（共有の基準となる履歴）から切り離して作業することです。AIへは一つの目的だけを頼みます。テストが通ったら、コミット（変更の記録）へ入る差分を人が確認します。

対象は、Gitリポジトリを作ったばかりの初心者です。Gitがインストール済みで、作業先のディレクトリがリポジトリになっていることを前提にします。複雑なgit rebase、強制プッシュ（git push --force）、マージコミットの復旧は扱いません。

安全な最小作業手順

1. 現在地を確認する
2. 作業用ブランチ（変更を分ける場所）を作る
3. AIへ変更対象・非対象・テストを渡す
4. 状態と差分を読む
5. テストを実行する
6. 次のコミットへ入れる差分だけステージする
7. ステージ済みの差分を再確認してコミットする
8. プルリクエスト（PR）でレビューする

1. 作業前の状態を確認する

git status --short
git branch --show-current
git log -5 --oneline

3つの結果を確認してから進みます。

確認	進める状態	止まる状態
git status --short	何も表示されない、または今回の一目的だけが表示される	目的や所有者が分からない変更、別作業の変更がある
git branch --show-current	mainなど、基準にするブランチ名が表示される	何も表示されない。detached HEAD（特定のブランチから外れた状態）の可能性がある
git log -5 --oneline	直近のコミットが表示される	履歴がなく、初回コミットもまだない

未コミット変更が今回の作業だけなら、内容を確認したうえで作業用ブランチへ移します。関係のない変更が混ざっている場合は、変更を増やしません。

detached HEADから作業を保護する

git branch --show-currentの結果が空なら、まず現在地を確認します。

git status --short
git log -1 --oneline
git branch --all

現在の変更やコミットを残す必要がある場合、または判断できない場合は、救出用ブランチへつなぎます。

git switch -c rescue/detached-work
git branch --show-current

rescue/detached-workと表示されれば、現在の作業を指すブランチができています。ここで差分を確認し、必要ならコミットします。

残す変更がなく、mainが基準ブランチだと確認できた場合だけ戻ります。次の経路へ進む前に、git status --shortが空であることが条件です。

git status --short
git switch main
git branch --show-current

mainが存在しない、切り替えに失敗する、現在のコミットを残すべきか分からない場合は止めます。迷うときは先に救出用ブランチを作るほうが、作業を失いにくくなります。

初回コミットを作る

初回コミットがまだない場合は、最初に.gitignoreを作成または確認します。環境変数ファイル、秘密鍵、認証トークン、依存パッケージ、不要な生成物が含まれていないことを確かめます。除外項目はプロジェクトごとに違うため、意味の分からない一覧をそのまま貼り付けません。

path/to/checked-fileは実際のパスへ置き換えます。

git status --short
git add .gitignore
git add path/to/checked-file
git diff --staged
git commit -m "Initial commit"
git status --short
git log -1 --oneline

git diff --stagedに秘密情報や意図しないファイルがあれば、コミットへ進みません。成功後はgit log -1 --onelineにInitial commitが表示されます。git status --shortは空、または意図して残した未追跡ファイルだけなら次へ進めます。

利用者名やメールアドレスの設定を求めるエラーが出た場合は、使用する名前とメールアドレスを決めてから、このリポジトリだけに設定します。YOUR_NAMEとYOUR_EMAILは自分の値へ置き換え、他人の情報やアクセストークンを入れません。

git config --local user.name "YOUR_NAME"
git config --local user.email "YOUR_EMAIL"
git config --local --get user.name
git config --local --get user.email
git diff --staged
git commit -m "Initial commit"

表示された本人情報とステージ済み差分を再確認してから、止まっていたコミットをやり直します。

履歴を確認できたら、一目的のブランチを作ります。

git switch -c feat/add-search-filter

作成後にgit branch --show-currentをもう一度実行し、feat/add-search-filterと表示されれば次へ進めます。

GitHubでは、ブランチ上の変更をプルリクエスト（変更内容を共有して確認する機能）として提案し、レビュー後にベースブランチへ統合できます。公式のプルリクエスト解説で流れを確認できます。一人開発でも、変更をmainから分け、説明とテスト結果を残す場所として使えます。

2. AIへは一つの目的ずつ依頼する

「検索を良くして」のような依頼では差分が広がります。

目的:
変更してよいファイル:
変更しないファイル:
受入条件:
実行するテスト:
完了時に報告する内容:

GitHub Copilotの推奨手順は、複雑な作業を小さく分け、要件や入力、期待する出力を具体化し、生成されたコードをレビュー・テストするよう案内しています。Copilot向けの資料ですが、変更範囲を小さくする考え方は、ほかのコーディング支援AIにも使えます。

3. 未ステージ差分を読む

AIの完了報告ではなく、リポジトリの状態を見ます。

git status --short
git diff

git-status公式ドキュメントによると、git statusはHEAD（現在のコミット）とindex（次のコミットに入れる変更を置く場所）、indexと作業ツリー（編集中のファイル群）の差に加え、未追跡ファイルを示します。オプションを付けないgit diffは作業ツリーとindexの差、つまりまだステージしていない変更を表示します。比較対象はgit-diff公式ドキュメントで確認できます。

未追跡ファイルの内容はgit diffだけでは表示されません。git statusで見つけ、エディターや安全な閲覧コマンドで中身を確認します。

確認する点は次のとおりです。

• 依頼していないファイルが変わっていないか
• テストを削除・無効化していないか
• 秘密情報、個人情報、デバッグ出力が入っていないか
• 依存関係やロックファイルが増えていないか
• エラー処理と権限確認が消えていないか

4. テストして必要な差分だけステージする

ステージとは、次のコミットへ入れる変更を選ぶ操作です。その前に、利用できるnpm script（package.jsonに登録されたコマンド）を確認します。

npm run

表示されたコマンドとリポジトリのREADMEを見て、定義済みのテストを選びます。次はscriptが存在する場合の例です。

npm test
npm run lint
npm run build

scriptが見つからない場合や、コマンドがエラーで終わった場合はステージへ進みません。テストを直すか、受入条件を確認できる別の手順を決めます。成功したコマンドと結果はプルリクエストへ残します。

既存ファイルから必要な差分だけを選ぶには、次を使えます。

git add -p

git-add公式ドキュメントによると、--patchは差分のまとまりごとにステージする対話モードです。代表的な入力は、yが現在の差分をステージ、nが見送り、sが差分の分割、qが終了です。qを選んでも、それまでyで選んだ差分はステージ済みのまま残ります。取り消しではないため、終了後にgit diff --stagedで確認します。相互依存する変更は無理に分けません。

git add -pに出ない未追跡の新規ファイルは、内容を確認してから明示的に追加します。path/to/new-fileは実際のパスへ置き換えます。

git add path/to/new-file

5. 次のコミットに入る内容を再確認する

git diff --staged
git status --short

git diff --stagedはindexとHEADを比べ、次のコミットに入る差分を示します。意図した一つの目的だけが入っていれば、コミットします。

git commit -m "Add search result filters"

コミットメッセージは、「何を変えたか」が分かる短い命令形にします。コード整形だけの変更や別機能は、機能変更とは別のコミットへ分けます。

6. GitHubへpushしてPRを作る

remoteは、手元のGitとGitHub上のリポジトリを結ぶ接続先です。最初にoriginの有無とURLを確認します。

git remote -v

originが表示されたら、GitHubで開いている対象リポジトリのURLと所有者名が一致するかを確認します。知らないリポジトリ、別の所有者、別プロジェクトを指している場合はpushしません。URLへパスワードやアクセストークンが埋め込まれている場合も止めます。

originが未設定の場合

GitHub側で空のリポジトリを作り、その画面からURLをコピーします。README、ライセンス、.gitignoreをGitHub側で追加して履歴を作った場合は、ここでいう空のリポジトリではありません。

originがまだ存在しない場合だけ、コピーしたURLを登録します。次のURLは自分の所有者名とリポジトリ名へ置き換えます。

git remote add origin https://github.com/OWNER/REPOSITORY.git
git remote -v
git ls-remote origin

git remote -vへ意図したURLが表示され、空のリポジトリならgit ls-remote originには参照が表示されません。認証エラー、知らない参照、想定外のURLが出た場合は進みません。既存のoriginへgit remote add originを重ねることも避けます。

空のリポジトリへmainを送る

GitHub側が空だと確認できた場合は、基準となるmainを先にpushします。git status --shortに何も表示されず、初回コミットが期待どおりに存在し、現在の作業ブランチ名も分かっていることが条件です。

git status --short
git branch --show-current
git log -1 --oneline
git switch main
git push -u origin main
git switch feat/add-search-filter

pushが拒否された場合は、GitHub側に想定外の履歴がないか確認します。--forceは使いません。mainへ戻したあとに作業ブランチへ切り替えられない場合も、変更を増やさず停止します。

既存のoriginを使う場合は、次のコマンドでGitHub側のmainを確認できます。

git ls-remote --heads origin main
git fetch origin
git log --oneline --decorate --graph --all -10

ハッシュ値とrefs/heads/mainが表示されれば、PRの比較先となるmainがあります。続く履歴表示で、手元の作業ブランチとorigin/mainが同じ履歴から分かれていることも確認します。何も表示されない、履歴が別々に見える、読み方が分からない場合はpushせず、基準ブランチと取得方法を確認します。

作業ブランチをpushしてPRを作る

git branch --show-current
git status --short
git log -1 --oneline
git push -u origin feat/add-search-filter

ブランチ名がfeat/add-search-filterではない場合や、git status --shortに未確認の変更がある場合はpushを保留します。認証エラーやremote側の拒否が出た場合も、強制pushへ切り替えません。

pushできたらGitHubでリポジトリを開き、作業ブランチからベースブランチ（この例ではmain）へのPRを作ります。送信前に変更ファイル一覧を読み、次の判断材料を本文へ残します。

## 目的
何の問題を解く変更か

## 変更
主要な差分

## 非対象
今回変えていないもの

## 確認
- npm test
- npm run build

## リスクと戻し方
影響範囲、機能フラグ、git revert、データ移行

AIレビューは補助に使えますが、正式な承認条件はチームで決めます。一人開発では、利用できる場合はDraft PR（下書きのPR）にするか、すぐ統合せず時間を置いて差分を読み直す方法があります。AI生成コードを確認する詳しい観点は安全なレビューチェックリストを参照してください。

共有済みの変更を戻す

共有済みコミットを取り消す場合も、最新のorigin/mainから専用ブランチを作ります。作業中の変更がなく、originが意図したリポジトリを指していることを先に確認します。

git status --short
git remote -v
git fetch origin
git switch -c revert/undo-search-filter origin/main
git log --oneline
git show COMMIT_ID
git revert COMMIT_ID
git log -1 --oneline

最初のgit status --shortに何か表示された場合や、fetchとブランチ作成に失敗した場合はrevertを始めません。git-revert公式ドキュメントによると、git revertは既存コミットの変更を打ち消す新しいコミットを作ります。完了後に新しいコミットが表示されれば、取り消した経緯も履歴へ残ります。

競合でrevertが止まった場合は、内容を推測して直さず、いったん中止できます。

git status
git revert --abort
git status --short

中止後は、どのファイルと後続変更が競合したかをissue（作業記録）へ残します。競合を説明できるまで再実行しません。マージコミットや後続変更との競合では、Gitの変更を単純に戻せないことがあります。

revertが成功したら、npm runで存在を確認したテストだけを実行します。次はtestとbuildが定義済みの場合の例です。

npm test
npm run build
git status --short
git push -u origin revert/undo-search-filter

テストが失敗した場合や、git status --shortへ未確認の変更が出た場合はpushしません。成功後はrevert/undo-search-filterからmainへのPRを作り、戻したコミット、理由、テスト結果、データへの影響を記録します。

データ移行は、アプリケーションコードのgit revertとは別に復旧方法を用意します。内容が分からないままgit reset --hardや強制プッシュを実行するのは避けます。

コミット前チェックリスト

[ ] 一つの目的だけか
[ ] 未追跡ファイルも確認したか
[ ] ステージ済みの差分を読んだか
[ ] テストを実行したか
[ ] 秘密情報と個人情報がないか
[ ] 依存関係追加を確認したか
[ ] 戻し方を書いたか

Gitだけで品質は保証できません。それでも、小さな差分と判断履歴が残っていれば、AIの誤りを見つけて戻すときの手掛かりになります。