Git を、AIの変更を戻せるようにするための道具として使う

開発を手伝うAIを入れると、コードが増える速さが変わります。読む速さは変わりません。

この差を吸収するのが Git です。読み切れないほどの量が出てきたときに、「いったん全部なかったことにする」ができれば、受け入れる判断を急がずに済みます。逆に、その手段がないと、読み切れていないものを受け入れるしかなくなります。

この回で扱うのは Git の全機能ではありません。Codex が書いたものを、読み、戻し、次に渡すために要る部分だけに絞ります。

ファイルが置かれる3つの場所

Git を難しくしているのは、同じファイルが3つの場所に同時にあることです。

Codex が編集すると、変わるのは作業ツリーだけです。履歴は動きません。だから、作業ツリーの変更が気に入らなければ、履歴の状態に戻せば消えます。Codex が何をしても、コミット済みの状態は壊れない。これが、Git の中で動かす一番の理由です。

覚えるのは6つで足りる

最初に要るコマンドは6つです。

git status          # いま何が変わっているか
git diff            # どう変わっているか
git add <file>      # この変更をコミットに含める
git commit -m "..."  # 履歴に確定させる
git log --oneline   # 過去のコミットを並べて見る
git restore <file>  # 作業ツリーの変更を捨てて、履歴の状態に戻す

このうち、Codex と組むときに一番よく打つのは git status と git diff です。依頼を出したあと、まずこの2つで範囲と中身を確かめます。第3回で書いた「触ったファイルの一覧を先に見る」は、git status の出力を見るということです。

差分が大きいときは、先に規模だけ見ます。

git diff --stat

ファイルごとの変更行数だけが出ます。「10ファイルに散っている」のか「1ファイルに集中している」のかが、中身を読む前に分かります。想定と違えば、そこで止めます。

変更を戻す3段階

戻し方は、どこまで進んだかで変わります。3つ覚えておけば足ります。

まだコミットしていない変更を捨てるときは git restore です。ファイル名を指定すればそのファイルだけ、. を指定すれば作業ツリー全体が履歴の状態に戻ります。Codex の出した差分が気に入らないときは、これで消します。

コミットしてしまった変更を打ち消すときは git revert です。過去のコミットを消すのではなく、それを打ち消す新しいコミットを積みます。履歴が残るので、他の人と共有しているブランチでも安全に使えます。

過去の状態を見たいだけのときは git show <コミット> です。戻さずに中身だけ確認できます。

1つの依頼に、1つのコミット

粒度の話です。結論から書くと、1つの依頼に1つのコミットを目安にしてください。

理由は2つあります。ひとつは、戻す単位が依頼の単位と揃うことです。「あの依頼の結果だけ取り消したい」がそのままできます。

もうひとつは、あとから履歴を読んだときに意味が分かることです。3つの依頼の結果が1つのコミットに混ざっていると、半年後に git log を見ても、何が何のための変更だったのか読み取れません。

この目安が守れないときは、コミットの切り方ではなく依頼の大きさのほうを疑ってください。1つの依頼で20ファイルが変わるなら、依頼が大きすぎます。

コミットメッセージは Codex に下書きさせて構いません。ただし、そのまま使わないでください。差分を読めば「何を変えたか」は分かります。分からないのは「なぜ変えたか」で、これは依頼した人にしか書けません。1行足すだけで、履歴の価値はかなり変わります。

ブランチは、試したものを捨てられる場所

ブランチは、履歴の枝分かれです。

git switch -c feature/wareki   # 新しい枝を作って移る
git switch main                # 元の枝に戻る
git branch -d feature/wareki   # 枝ごと捨てる

Codex と組むときのブランチの使い方は、ひとつだけ覚えておけば足ります。試すことが決まっていない作業は、必ず枝の上でやる。

うまくいけば元の枝に取り込みます。うまくいかなければ枝ごと捨てます。捨てられると分かっていると、大きめの依頼を出すことへの抵抗が減ります。これは第5回で --worktree を紹介したときと同じ発想で、あちらはフォルダごと分ける形、こちらは履歴の上で分ける形です。

取り込むときは git merge です。

git switch main
git merge feature/wareki

同じ場所を両方の枝で変えていると、取り込みで衝突します。衝突したファイルには両方の変更が印つきで並ぶので、どちらを残すかを決めて、印を消して、コミットします。この解決を Codex に任せることもできますが、最初のうちは自分でやってください。衝突は「2人が同じ場所を別の意図で触った」という意味なので、意図を知っている人が決めたほうが速く終わります。

履歴に入れてはいけないもの

最後に、入れないものの話です。

APIキー、アクセストークン、パスワード、個人情報を含むデータ。これらは一度コミットすると、あとで消しても履歴には残ります。公開リポジトリなら、その時点で漏れたものとして扱うことになります。

対策は .gitignore です。追跡しないファイルとフォルダを、この1ファイルに書いておきます。

.env
.env.local
node_modules/
*.key

Codex に「設定ファイルを作って」と頼んだとき、鍵の値を直接書き込んだファイルが出てくることがあります。差分を読むときに、鍵らしき文字列が新しく入っていないかを見る癖をつけてください。第2回で、APIキーを引数に書かない形が用意されていることに触れました。同じ理由です。

次の回

これで、手元で変更を管理できるようになりました。第8回では、その変更を他人に見せる場所へ出します。GitHub の Issue とプルリクエストです。Codex に任せた変更を人がレビューする流れは、ここで形になります。

参照した情報

• Git 公式ドキュメント（git-scm.com）の各コマンドの仕様
• コマンドライン版 Codex の --skip-git-repo-check などの引数は codex-cli 0.154.0 を執筆環境へ導入して取得