Gitは、コーディングエージェントを扱ううえで重要なツールです。コードをバージョン管理しておくことで、時間の経過とともにそのコードがどう変化したかを記録でき、ミスを調べたり取り消したりできます。すべてのコーディングエージェントは、Gitの基本機能から高度な機能まで、使いこなせます。

この習熟によって、私たちは自分たちがGitを使う方法について、より野心的になれます。Gitでどうやるのかを暗記する必要はありませんが、可能なことを意識していれば、Gitの能力のフルスイートを活用できます。

Gitの要点

それぞれのGitプロジェクトはリポジトリ（その中のファイルに加えられた変更を追跡できる、ディスク上のフォルダ）に存在します。これらの変更はコミットとして記録されます。コミットとは、1つ以上のファイルへの変更を時刻付きで束ねたものであり、その変更を説明するコミットメッセージと、作成者を記録するauthor（誰が行ったか）を伴います。

Gitはブランチをサポートしており、互いに独立した新しい変更を、別々に構築して実験できます。準備ができたと判断したら、ブランチを（さまざまな方法で）元のメインブランチにマージできます。

Gitリポジトリは、別の新しいマシンにクローンできます。このクローンには、現在のファイルだけでなく、それらへの変更の完全な履歴も含まれます。 そのため、開発者（またはコーディングエージェント）は追加のネットワーク通信なしに、その履歴を閲覧・探索でき、履歴の掘り下げが事実上無料になります。

Gitリポジトリは自分のマシン上だけに置くこともできますが、Gitは、これらをリモートに公開することで、コラボレーションやバックアップをサポートするよう設計されています。リモートは公開または非公開にできます。GitHubはそうしたリモートを置く最も人気の場所ですが、Gitはオープンソースソフトウェアなので、Gitプロトコルに対応しているあらゆるマシンやサービスで、これらのリモートをホスティングできます。

中核となる概念とプロンプト

コーディングエージェントは、Gitの専門用語を深く理解しています。以下のプロンプトは、どれでも同様に機能するはずです。

>エージェントが作業しているフォルダをGitリポジトリにするには、たぶんgit initコマンドを実行するでしょう。単に「repo」と言えば、エージェントはそれがGitリポジトリだと解釈します。 >エージェントが行った変更を記録する新しいGitコミットを作成します。通常はgit commit -m "コミットメッセージ"のコマンドを使います。 >これにより、リポジトリがGitHub向けに設定されます。まずはgithub.com/newで新しいリポジトリを作成し、マシンをGitHubと通信できるように設定する必要があります。 >または「最近の変更」や「直近3つのコミット」。

これは、新しいコーディングエージェントのセッションを始めるのにとても良い方法です。エージェントに「最近の変更」を見させるとgit logが実行され、最近あなたが取り組んでいた内容――変更されたコードと、それを説明するコミットメッセージの両方――の詳細を、即座にコンテキストとして読み込めます。

このようにセッションを仕込んでおけば、そのコードについて会話を始められます。追加の修正案を提案したり、動作の仕組みについて質問したり、これまでの内容を土台に次に行う変更を提案したりできます。

>これをメインブランチで実行すれば、リモートリポジトリから他の貢献を取得できます。あるいはブランチ上で実行して、main上の最新の変更を統合できます。

変更をマージする方法はいくつもあります。マージ、リベース、スクワッシュ、またはファストフォワードなどです。これらの詳細を覚えていなくても大丈夫です:

>エージェントは、異なるマージ戦略の長所と短所を説明するのが得意です。そして、gitのすべては常に元に戻せるので、新しいことを試してもリスクは最小限です。

この汎用プロンプトは、意外なほど頻繁に使っています！こちらの最近の例では、マージ競合で失敗したチェリーピックを直してくれました。

Gitでややこしい状態に陥る方法はたくさんあります。プルやリベースのコマンドがマージ競合で行き詰まることもあれば、単にGitのステージング環境に間違ったものを追加してしまうこともあります。

これらのほぐし方は、以前はGit作業の中で最も難しく時間のかかる部分でした。もう終わりです！コーディングエージェントなら、最も複雑なマージ競合でも対処できます。新しいコードの意図を推論し、何を残してどう競合する変更同士を組み合わせるかを考えます。コードに自動テストがあるなら（そしてそうであるべき）そのマージを最終確定する前に、それらが通ることをエージェントが保証できます。

>以前コミットされていた（またはgit stashで保存されていた）作業中のコードを失ってしまった場合、エージェントはおそらく見つけてくれます。

Gitにはreflogという仕組みがあり、永続的なブランチにコミットされていないコードの詳細を記録していることが多いです。エージェントはそれを検索でき、他のブランチも検索できます。

見つけてほしいものを伝え、潜っていくのを見守るだけです。

>Git bisectは、Gitのデバッグ用ツールの中でも最強クラスの1つですが、学習コストが比較的高く、それが原因で多くの開発者が使うのを避けがちです。

bisect操作を実行するとき、Gitにある種のテスト条件と、開始・終了するコミット範囲を渡します。するとGitは二分探索を行い、テスト条件が失敗する最も早い（最初の）コミットを特定します。

これにより「このバグを最初に引き起こしたのは何か」という問いに、効率よく答えられます。唯一の欠点は、Git bisectが実行できる形式でバグのテストを表現する必要があることです。

コーディングエージェントなら、この定型文（ボイラープレート）をあなたの代わりに処理できます。これにより、Git bisectは「たまに使うツール」から、「ソフトウェアの過去の振る舞いが気になったときならいつでも投入できる」ものへと格上げされます。

履歴の書き換え

楽しい高度な話に入りましょう。

Gitリポジトリのコミット履歴は固定されたものではありません。データは結局のところディスク上のファイルであり（隠しディレクトリの.git/にしまわれています）、Git自身にも、その履歴を変更するために使えるツールが用意されています。

Gitの履歴を、実際に起きたことの恒久的な記録だと思わないでください。代わりに、それはソフトウェアプロジェクトの進行を描写する、意図的に著された物語だと考えてください。

この物語は、将来の開発を助けるためのツールです。過去の誤りや取り消された方向性を永久に記録しておくことが役立つ場合もありますが、リポジトリの著者は、何を残すか、そしてその履歴を最もよくどう記録するかについて編集上の判断を行えます。

コーディングエージェントは、Gitの高度な履歴書き換え機能を使うのが本当に得意です。

コミットを取り消す、または書き換える

コードをコミットしてから後悔するのはよくあることです。たとえば、意図していなかったファイルが含まれていたことに気づく、といったケースです。このときのgitの手順はgit reset --soft HEAD~1です。私はそれを覚えられたことが一度もなかったのですが、これで覚えなくてよくなりました！ また、コミットに対してもっと細かい手術もできます。たとえば、単一のファイルだけを削除するためにコミットを書き換える、といった具合です。 エージェントはコミットメッセージを書き換えられ、複数のコミットを1つのまとまりに統合することもできます。

フロンティアモデルは、通常かなりセンスの良いコミットメッセージを出してくれることが多いと感じています。以前は私は自分でこれらを書こうと固く主張していましたが、彼らが生み出す品質は概ね十分どころか、しばしば自分が出すものよりも良いことを受け入れるようになりました。

古いリポジトリの“端切れ”から新しいリポジトリを作る

私がかなりの頻度で使っているコツは、大きなリポジトリからコードを切り出して新しいリポジトリに移し、そのコードの重要な履歴を維持することです。

よくある例が、ライブラリの抽出です。あるプロジェクトの中にクラスや関数を作り込んでおいて、後になって、それらはスタンドアロンの再利用可能なコードライブラリとして切り出したほうが理にかなっていると気づくことがあります。

この種の操作は以前は手間がかかりすぎて、ほとんどの開発者は古いコミット履歴から切り離した新しいコピーを作ることになりがちでした。けれど、もうそれに甘んじる必要はありません！

これはガイド Agentic Engineering Patterns の1章です。

coding-agents 182 generative-ai 1706 github 182 agentic-engineering 32 ai 1924 git 52 llms 1672

作成日: 2026年3月21日
最終更新日: 2026年3月23日
5件の変更

前: コーディングエージェントはどのように動くか

次: サブエージェント