Using Git with coding agents｜コーディングエージェントでのGitの活用

*[Agentic Engineering Patterns](https://simonwillison.net/guides/agentic-engineering-patterns/) >* Git はコーディングエージェントとの連携において重要なツールです。コードをバージョン管理下に置くことで、そのコードが時間とともにどのように変化してきたかを記録し、ミスを調査したり元に戻したりすることが可能になります。すべてのコーディングエージェントは、Git の基本的な機能から高度な機能までを自在に使いこなすことができます。 この習熟度の高さにより、私たちが Git を使用する際にもより野心的なアプローチが可能になります。Git で何を行うかの「方法」を暗記する必要はありませんが、何が可能なかを知っておくことで、Git の全機能を最大限に活用できるのです。 ## Git essentials 各 Git プロジェクトは**リポジトリ**（repository）と呼ばれるディスク上のフォルダ内に存在し、そのフォルダ内のファイルに加えられる変更を追跡します。これらの変更は**コミット**（commit）として記録されます。コミットとは、1 つ以上のファイルに対する変更のタイムスタンプ付きの束であり、それらの変更を説明する**コミットメッセージ**（commit message）と、誰が変更を加えたかを記録する**著者**（author）情報を含んでいます。 Git は**ブランチ**（branch）をサポートしており、これにより新しい変更を互いに独立して構築・実験することが可能になります。これらのブランチは、準備ができたと判断された時点で、さまざまな方法を用いてメインブランチに**マージ**（merge）することができます。 Git リポジトリは新しいマシンへ**クローン**（clone）することもでき、そのクローンには現在のファイルとそれらに対する変更の完全な履歴が含まれます。これにより、開発者やコーディングエージェントは追加のネットワークトラフィックを必要とせずに履歴を検索・探索することができ、履歴の遡行が事実上無料で行えるようになります。 Git リポジトリはあなたのローカルマシン上にのみ存在させることもできますが、Git はパブリックまたはプライベートの**リモート**に公開することでコラボレーションとバックアップをサポートするように設計されています。これらのリモートの最も人気のある場所は GitHub ですが、Git はオープンソースソフトウェアであり、Git プロトコルをサポートする任意のマシンやサービス上でこれらのリモートをホストすることを可能にします。 ## コア概念とプロンプト コーディングエージェントはすべて Git の専門用語を深く理解しています。以下のプロンプトはどのエージェントでも機能します: ここで新しい Git リポジトリを開始する エージェントが作業中のフォルダを Git リポジトリに変換するには - エージェントはおそらく `git init` コマンドを実行します。単に「リポジトリ」と言うだけで、エージェントは Git リポジトリを意味していると解釈します。 これらの変更をコミットする エージェントが行った変更を記録するために新しい Git コミットを作成します - 通常は `git commit -m "コミットメッセージ"` コマンドを使用します。 username/repo を GitHub のリモートとして追加する これにより、リポジトリが GitHub 用に設定されます。まず [github.com/new](https://github.com/new) を使用して新しいリポジトリを作成し、マシンを GitHub と通信するように構成する必要があります。 今日行われた変更を確認する または「最近の変更」や「直近の 3 つのコミット」としても構いません。 これは、新鮮なコーディングエージェントセッションを開始するための素晴らしい方法です。エージェントに最近の変更を確認させることで、`git log` が実行され、最近作業していた内容の詳細（修正されたコードとそれを説明するコミットメッセージ）を即座にコンテキストとして読み込むことができます。 このようにセッションを開始することで、そのコードについて話し始めることができます。追加の修正を提案したり、動作方法について質問をしたり、これまでの成果に基づいた次の変更を提案したりすることが可能になります。 main ブランチから最新の変更を取り込む リモートリポジトリからの他の貢献を取得するには main ブランチでこのコマンドを実行するか、または main の最新の変更を取り込むためにブランチ内で実行します。 変更をマージする方法は複数あります。マージ、rebase（リベース）、squash（スクワッシュ）、fast-forward（ファストフォワード）などです。これらの詳細を覚えていなくても問題ありません。 main ブランチからの統合に関するオプションについて議論する エージェントは異なるマージ戦略の長所と短所を説明するのが得意であり、Git の操作はすべて元に戻せるため、新しい試みには最小限のリスクしか伴いません。 この Git の混乱を整理してください 私はこの汎用プロンプトを意外なほど頻繁に使用しています！Git で混乱に陥る方法はたくさんあります。多くの場合、マージ競合で終わるプルやリベースコマンドを通じて、あるいは Git のステージング環境に誤ったものを追加することで発生します。 Git を使った作業において、これらはこれまで最も困難で時間のかかる部分でした。もうそんなことはありません！コーディングエージェントは、最も複雑なマージ競合さえもナビゲートし、新しいコードの意図を推論して、何を保持し、どのように競合する変更を組み合わせるかを判断できます。コードに自動テストがある場合（そしてあるべきです）、そのマージを確定する前にテストが通ることをエージェントが保証してくれます。 ...を行う私のコードを見つけ出して復元する 以前にコミットされた（または git stash で保存された）作業中のコードを失った場合、エージェントがおそらく見つけてくれます。 Git には reflog という仕組みがあり、恒久的なブランチにコミットされていないコードの詳細をしばしばキャプチャできます。エージェントはこの reflog を検索し、他のブランチも検索できます。 何を見つけたいか指示するだけで、エージェントが深く掘り下げるのを眺めていればよいのです。 このバグが導入された時期を git bisect で見つける：... git bisect は Git の武器庫の中で最も強力なデバッグツールの一つですが、学習曲線が比較的急で、多くの開発者が使用することをためらわせています。 bisect 操作を実行する際、Git にテスト条件と開始・終了コミット範囲のいずれかを指定します。Git はその後、バイナリ検索を実行して、テスト条件が失敗する最も早いコミットを特定します。 これは「このバグを最初に引き起こしたのは何か」という質問に効率的に答えることができます。唯一の欠点は、Git bisect が実行できる形式でバグのテストを記述する必要があることです。 コーディングエージェントは、このような定型部分を処理してくれます。これにより、Git bisect は「時々使うツール」から、「ソフトウェアの過去の挙動について疑問を持ったときにいつでも展開できるツール」へと進化します。 ## 履歴の書き換え では、面白い高度な機能を見ていきましょう。 Git リポジトリのコミット履歴は固定されていません。データは結局のところディスク上のファイルに過ぎず（隠しディレクトリ .git/ に格納されています）、Git 自体にはその履歴を変更するためのツールが用意されています。 Git の履歴を「実際に何が起こったか」の永続的な記録として捉えるのではなく、ソフトウェアプロジェクトの進行過程を記述した意図的に編集された物語であると考えるべきです。 この物語は、将来の開発を支援するための道具です。間違いや中止された方向性を永久に記録することが役立つ場合もありますが、リポジトリの作成者は、何を保持し、どのように履歴を最もよく捉えるかについて編集上の判断を下すことができます。 コーディングエージェントは、Git の高度な履歴書き換え機能を非常にうまく活用できます。 ## コミットの取り消しまたは書き換え 直前のコミットを取り消す コードをコミットした後で後悔することはよくあります。例えば、意図しないファイルが含まれてしまっていることに気づく場合などです。これに対する Git のレシピは `git reset --soft HEAD~1` です。私はこれまでこのコマンドを覚えることができませんでしたが、今ではその必要もありません！ 直前のコミットから uv.lock を削除する コミットに対してより細かな手術を行うことも可能です。例えば、単一のファイルだけを削除するためにコミットを書き換えるといった操作です。 最後の 3 つのコミットを、より適切なコミットメッセージと共に結合する エージェントはコミットメッセージの書き換えや、複数のコミットを単一単位に統合することもできます。 私が経験したところによると、最先端のモデルはコミットメッセージに対する審美性が非常に優れています。以前は自分でこれらを書くことに固執していましたが、現在では彼らが生成する品質が一般的に十分であり、むしろ自分自身で書くものよりも優れた場合さえあると受け入れています。 ## 古いリポジトリの断片から新しいリポジトリを構築する 私がよく使うテクニックの一つは、コードの主要な履歴を維持したまま、大きなリポジトリからコードを抽出して新しいリポジトリに移すというものです。 よくある例として、ライブラリの抽出があります。プロジェクト内にいくつかのクラスや関数を実装した後で、それらを独立した再利用可能なコードライブラリとした方がより適切だと気づく場合があります。 /tmp/distance-functions に新しいリポジトリを開始し、ここにある lib/distance_functions.py モジュールを使って Python ライブラリを構築する - 新しいリポジトリ内で著者名とコミット日時をコピーして同様のコミット履歴を構築する このような操作は以前は複雑すぎて、多くの開発者が古いコミット履歴から切り離された新規コピーを作成していました。しかし、もうそんな妥協をする必要はありません！ Tags: [coding-agents](https://simonwillison.net/tags/coding-agents), [generative-ai](https://simonwillison.net/tags/generative-ai), [github](https://simonwillison.net/tags/github), [agentic-engineering](https://simonwillison.net/tags/agentic-engineering), [ai](https://simonwillison.net/tags/ai), [git](https://simonwillison.net/tags/git), [llms](https://simonwillison.net/tags/llms) コーディングエージェント（coding agents）と Git を連携させる方法について、シリーズ最終回（7/7）です。 前回のエピソードでは、エージェントが生成したコードをどのようにレビューし、マージするかというプロセスの一部を紹介しました。今回は、より具体的なワークフローと、エージェントとの協働における Git の役割を深掘りします。 まず、エージェントが作業を開始する前に、必ず新しいブランチを作成させることが重要です。例えば、`feature/agent-improvement-20240521` のような名前を付与し、そのブランチ上ですべての変更を加えさせます。これにより、メインのコードベース（main ブランチや develop ブランチ）が汚染されるリスクを防ぎます。 エージェントは、通常、小さなコミット単位で作業を進めます。各コミットには、何を変更したのかを明確に記述したメッセージを含めるよう指示します。例えば、「ユーザー認証ロジックの最適化」「データベースクエリのパフォーマンス改善」などです。これにより、後から変更履歴を追跡しやすくなります。 レビュープロセスでは、エージェント自身にも自己レビューの役割を持たせることができます。生成されたコードに対して、まず自分自身でコメントやテストケースを追加させ、その後に人間が最終確認を行うという二段構えのチェック体制を構築します。このアプローチにより、エラーの早期発見と品質向上が期待できます。 また、Git のフック（hooks）を活用して、エージェントによるコミットが自動的に検証されるように設定することも有効です。例えば、pre-commit フックでコードフォーマッターを実行させたり、lint ツールで静的解析を行ったりします。これにより、人間の手を介さずに一貫した品質基準を保つことが可能になります。 マージ時には、リベース（rebase）ではなく、マージコミット（merge commit）を使用することを推奨します。エージェントの作業履歴が分岐として残るため、後からどの変更がいつ行われたかを明確に把握できます。特に大規模なプロジェクトでは、この可視性が重要です。 最後に、エージェントとの協働において最も重要なのは、人間と機械の役割分担を明確にすることです。エージェントは反復的なタスクや大量のコード生成を担当し、人間はアーキテクチャの設計、セキュリティの確認、最終的な意思決定を行います。Git はこの協働を支える基盤として機能します。 次回のシリーズでは、別のトピックを取り上げる予定です。ご期待ください！

コーディングエージェントでのGitの活用

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト