コーディングエージェントでのGitの活用
Simon Willison氏は、Gitがコーディングエージェントの作業において重要なツールであり、エージェントがGitの基本から高度な機能まで習熟していることで、開発者がGitの全機能を活用できるようになると述べている。
キーポイント
Gitはコーディングエージェントのキーツール
バージョン管理によりコードの変更履歴を記録・調査・修正可能にし、全てのコーディングエージェントがGitの基本・高度機能に習熟している。
Gitの基本概念とエージェントへの指示
リポジトリ、コミット、ブランチ、マージ、クローン、リモートなどのGitの基本概念を説明し、エージェントに対する具体的なプロンプト例を提示している。
開発者のGit活用能力の拡張
エージェントがGit操作を担当することで、開発者は操作方法を暗記する必要がなくなり、Gitの全機能を活用する可能性に集中できる。
影響分析・編集コメントを表示
影響分析
この記事は、AIコーディングエージェントの実用的な運用パターンを具体化し、Gitを介した開発ワークフローの効率化を示している。エージェントがGit操作を習熟することで、開発者はより戦略的なコード管理に集中できるようになり、AI支援開発の現実的適用を促進する可能性がある。
編集コメント
技術ブログの実践的ガイドとして、AIコーディングエージェントとGitの連携に関する具体的な知見を提供している。業界全体を変えるほどの革新性はないが、現場開発者にとって有用な実装パターンを提示している。
*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 を使用して新しいリポジトリを作成し、マシンを 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, generative-ai, github, agentic-engineering, ai, git, llms
コーディングエージェント(coding agents)と Git を連携させる方法について、シリーズ最終回(7/7)です。
前回のエピソードでは、エージェントが生成したコードをどのようにレビューし、マージするかというプロセスの一部を紹介しました。今回は、より具体的なワークフローと、エージェントとの協働における Git の役割を深掘りします。
まず、エージェントが作業を開始する前に、必ず新しいブランチを作成させることが重要です。例えば、feature/agent-improvement-20240521 のような名前を付与し、そのブランチ上ですべての変更を加えさせます。これにより、メインのコードベース(main ブランチや develop ブランチ)が汚染されるリスクを防ぎます。
エージェントは、通常、小さなコミット単位で作業を進めます。各コミットには、何を変更したのかを明確に記述したメッセージを含めるよう指示します。例えば、「ユーザー認証ロジックの最適化」「データベースクエリのパフォーマンス改善」などです。これにより、後から変更履歴を追跡しやすくなります。
レビュープロセスでは、エージェント自身にも自己レビューの役割を持たせることができます。生成されたコードに対して、まず自分自身でコメントやテストケースを追加させ、その後に人間が最終確認を行うという二段構えのチェック体制を構築します。このアプローチにより、エラーの早期発見と品質向上が期待できます。
また、Git のフック(hooks)を活用して、エージェントによるコミットが自動的に検証されるように設定することも有効です。例えば、pre-commit フックでコードフォーマッターを実行させたり、lint ツールで静的解析を行ったりします。これにより、人間の手を介さずに一貫した品質基準を保つことが可能になります。
マージ時には、リベース(rebase)ではなく、マージコミット(merge commit)を使用することを推奨します。エージェントの作業履歴が分岐として残るため、後からどの変更がいつ行われたかを明確に把握できます。特に大規模なプロジェクトでは、この可視性が重要です。
最後に、エージェントとの協働において最も重要なのは、人間と機械の役割分担を明確にすることです。エージェントは反復的なタスクや大量のコード生成を担当し、人間はアーキテクチャの設計、セキュリティの確認、最終的な意思決定を行います。Git はこの協働を支える基盤として機能します。
次回のシリーズでは、別のトピックを取り上げる予定です。ご期待ください!
原文を表示
*Agentic Engineering Patterns >*
Git is a key tool for working with coding agents. Keeping code in version control lets us record how that code changes over time and investigate and reverse any mistakes. All of the coding agents are fluent in using Git's features, both basic and advanced.
This fluency means we can be more ambitious about how we use Git ourselves. We don't need to memorize *how* to do things with Git, but staying aware of what's possible means we can take advantage of the full suite of Git's abilities.
Git essentials
Each Git project lives in a repository - a folder on disk that can track changes made to the files within it. Those changes are recorded in commits - timestamped bundles of changes to one or more files accompanied by a commit message describing those changes and an author recording who made them.
Git supports branches, which allow you to construct and experiment with new changes independently of each other. Branches can then be merged back into your main branch (using various methods) once they are deemed ready.
Git repositories can be cloned onto a new machine, and that clone includes both the current files and the full history of changes to them.
This means developers - or coding agents - can browse and explore that history without any extra network traffic, making history diving effectively free.
Git repositories can live just on your own machine, but Git is designed to support collaboration and backups by publishing them to a remote, which can be public or private. GitHub is the most popular place for these remotes but Git is open source software that enables hosting these remotes on any machine or service that supports the Git protocol.
Core concepts and prompts
Coding agents all have a deep understanding of Git jargon. The following prompts should work with any of them:
Start a new Git repo here
To turn the folder the agent is working in into a Git repository - the agent will probably run the git init command. If you just say "repo" agents will assume you mean a Git repository.
Commit these changes
Create a new Git commit to record the changes the agent has made - usually with the git commit -m "commit message" command.
Add username/repo as a github remote
This should configure your repository for GitHub. You'll need to create a new repo first using github.com/new, and configure your machine to talk to GitHub.
Review changes made today
Or "recent changes" or "last three commits".
This is a great way to start a fresh coding agents session. Telling the agent to look at recent changes causes it to run git log, which can instantly load its context with details of what you have been working on recently - both the modified code and the commit messages that describe it.
Seeding the session in this way means you can start talking about that code - suggest additional fixes, ask questions about how it works, or propose the next change that builds on what came before.
Integrate latest changes from main
Run this on your main branch to fetch other contributions from the remote repository, or run it in a branch to integrate the latest changes on main.
There are multiple ways to merge changes, including merge, rebase, squash or fast-forward. If you can't remember the details of these that's fine:
Discuss options for integrating changes from main
Agents are great at explaining the pros and cons of different merging strategies, and everything in git can always be undone so there's minimal risk in trying new things.
Sort out this git mess for me
I use this universal prompt surprisingly often! There are plenty of ways you can get into a mess with Git, often through pulls or rebase commands that end in a merge conflict, or just through adding the wrong things to Git's staging environment.
Unpicking those used to be the most difficult and time consuming parts of working with Git. No more! Coding agents can navigate the most Byzantine of merge conflicts, reasoning through the intent of the new code and figuring out what to keep and how to combine conflicting changes. If your code has automated tests (and it should) the agent can ensure those pass before finalizing that merge.
Find and recover my code that does ...
If you lose code that you are working on that's previously been committed (or saved with git stash) your agent can probably find it for you.
Git has a mechanism called the reflog which can often capture details of code that hasn't been committed to a permanent branch. Agents can search that, and search other branches too.
Just tell them what to find and watch them dive in.
Use git bisect to find when this bug was introduced: ...
Git bisect is one of the most powerful debugging tools in Git's arsenal, but it has a relatively steep learning curve that often deters developers from using it.
When you run a bisect operation you provide Git with some kind of test condition and a start and ending commit range. Git then runs a binary search to identify the earliest commit for which your test condition fails.
This can efficiently answer the question "what first caused this bug". The only downside is the need to express the test for the bug in a format that Git bisect can execute.
Coding agents can handle this boilerplate for you. This upgrades Git bisect from an occasional use tool to one you can deploy any time you are curious about the historic behavior of your software.
Rewriting history
Let's get into the fun advanced stuff.
The commit history of a Git repository is not fixed. The data is just files on disk after all (tucked away in a hidden .git/ directory), and Git itself provides tools that can be used to modify that history.
Don't think of the Git history as a permanent record of what actually happened - instead consider it to be a deliberately authored story that describes the progression of the software project.
This story is a tool to aid future development. Permanently recording mistakes and cancelled directions can sometimes be useful, but repository authors can make editorial decisions about what to keep and how best to capture that history.
Coding agents are really good at using Git's advanced history rewriting features.
Undo or rewrite commits
Undo last commit
It's common to commit code and then regret it - realize that it includes a file you didn't mean to include, for example. The git recipe for this is git reset --soft HEAD~1. I've never been able to remember that, and now I don't have to!
Remove uv.lock from that last commit
You can also perform more finely grained surgery on commits - rewriting them to remove just a single file, for example.
Combine last three commits with a better commit message
Agents can rewrite commit messages and can combine multiple commits into a single unit.
I've found that frontier models usually have really good taste in commit messages. I used to insist on writing these myself but I've accepted that the quality they produce is generally good enough, and often even better than what I would have produced myself.
Building a new repository from scraps of an older one
A trick I find myself using quite often is extracting out code from a larger repository into a new one while maintaining the key history of that code.
One common example is library extraction. I may have built some classes and functions into a project and later realized they would make more sense as a standalone reusable code library.
Start a new repo at /tmp/distance-functions and build a Python library there with the lib/distance_functions.py module from here - build a similar commit history copying the author and commit dates in the new repo
This kind of operation used to be involved enough that most developers would create a fresh copy detached from that old commit history. We don't have to settle for that any more!
Tags: coding-agents, generative-ai, github, agentic-engineering, ai, git, llms
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み