【ITニュース解説】Two Coding Agents Edited the Same File. Make Git Resolve It Once With rerere

現代のソフトウェア開発では、AIエージェントの活用が進んでいる。たとえば、あるAIエージェントにログイン機能のバグ修正を任せ、別のAIエージェントに認証部分の整理を依頼するといったケースが考えられる。それぞれのAIエージェントは独立したブランチで作業を進め、同じファイル内の異なる箇所、あるいは運悪く同じ行を修正することがある。

仮に、両方のAIエージェントがログイン処理を担当するsrc/login.jsというファイル内の特定の行を変更したとしよう。例えば、一方が空のパスワードを拒否する修正を行い、もう一方がユーザー名の前後の空白文字を削除する修正を加えたとする。それぞれの修正自体は理にかなっており、単独で見れば問題はない。しかし、これらを一つのブランチに統合しようとすると、同じ行が異なる内容で修正されているため、Gitで「競合」（コンフリクト）が発生する。

この競合を解決するには、開発者が手動で両方の修正内容を組み合わせ、正しい形にファイルを編集する必要がある。一度この解決作業を行ってコミットすれば、そのブランチでは問題ない。しかし、その後に別のブランチをメインブランチにリベースしたり、さらに別の変更をマージしようとしたりすると、全く同じ競合が再び発生することがある。そのたびに手動で同じ解決策を適用するのは非常に手間であり、開発者の貴重な時間を奪ってしまう。

このような、全く同じ競合が繰り返し発生する問題に対応するために、Gitにはrerereという便利な機能が用意されている。rerereは「reuse recorded resolution」の略で、直訳すると「記録された解決策を再利用する」という意味になる。この機能は、開発者が一度手動で解決した競合の内容をGitが記憶し、次に全く同じ競合が起きたときに、記憶した解決策を自動で適用してくれるというものだ。

rerereを有効にするには、Gitリポジトリのコンフィグレーションでgit config rerere.enabled trueと設定するだけでよい。一度有効にしておけば、そのリポジトリ内で発生する競合解決の管理がGitによって行われるようになる。

具体的な動作を見てみよう。二つのAIエージェントがそれぞれfix-loginブランチとtidy-authブランチで作業し、src/login.jsファイルに競合を引き起こす修正を行ったとする。まず、これらを統合するための試行として、一時的なブランチを作成し、両方のブランチの変更をマージしてみる。このマージの際に、src/login.jsで競合が発生する。

競合が発生すると、Gitはrerereが有効になっていることを検知し、競合発生時のファイルの状態（競合マーカーが含まれた状態）を「プレイメージ」として記録する。開発者はここで、両方のAIエージェントの修正を考慮し、競合した行を適切に編集してファイルを正しい状態に修正する。例えば、空のパスワードの拒否とユーザー名のトリミングの両方を反映した一行に修正する。ファイルを修正したら、git addで変更をステージングし、コミットを行う。このコミットの際に、Gitは開発者が手動で解決した内容を「解決済みイメージ」としてrerereのキャッシュに記録する。この記録が「一度解決した競合を記憶する」という動作だ。開発者はgit rerere statusやgit rerere diffコマンドを使って、rerereが何を記憶しようとしているかを確認できる。

一度解決内容が記録されれば、次に同じ競合が発生したときにrerereがその真価を発揮する。例えば、最初にfix-loginブランチの変更をメインブランチにマージし、その後にtidy-authブランチをメインブランチにリベースするシナリオを考えてみよう。このリベースの際に、以前に手動で解決した時と全く同じ競合がsrc/login.jsで再び発生する。しかし、rerereが有効であり、以前の解決内容が記録されているため、Gitは「Resolved 'src/login.js' using previous resolution.」といったメッセージを出力し、競合したファイルを自動的に以前に記録された解決済みの内容で書き換えてくれる。

これにより、開発者は再び手動でファイルを編集する手間が省ける。ただし、Gitは自動でファイルを書き換えてくれるものの、そのファイルを自動でステージングするわけではない。これは、自動解決された内容が本当に正しいかどうかを開発者が確認するための重要なステップだ。したがって、ファイルが自動解決された後も、開発者はその内容を確認し、git add src/login.jsでステージングし、その後git rebase --continueなどのコマンドで作業を続行する必要がある。

もし、rerereが以前記録した解決内容が、何らかの理由で今回の場合には不適切だったり、誤りを含んでいたりした場合はどうすればよいだろうか。そのような状況では、rerereの記録を一時的に破棄し、競合を再度手動で解決することが可能だ。具体的には、競合で停止している状態でgit rerere forget src/login.jsコマンドを実行すると、そのファイルに対する記録済みの解決内容を削除できる。その後、git checkout --conflict=merge src/login.jsで競合マーカーが挿入された状態にファイルを戻し、手動で正しく修正する。修正が完了したら、git addしてgit rerereを実行するか、コミットすることで、新しい正しい解決内容をrerereに記録させることができる。

rerereは非常に便利な機能だが、いくつかの制限事項も理解しておく必要がある。第一に、rerereは「全く同じ競合部分」（コンフリクトハンク）にしか適用されない。もし、AIエージェントが競合した行の周辺のコードを大幅に書き換え、結果として競合の発生場所や内容が少しでも異なれば、rerereはそれを新しい競合とみなし、自動解決は行われない。第二に、rerereはテキストベースの比較と解決を行う。コードの意味や全体的なコンテキストを理解しているわけではないため、自動解決されたコードが他の部分の変更と相まって意図しない不具合を引き起こす可能性もゼロではない。そのため、rerereが自動解決を行った後も、必ずテストを実行してコードの正しさを確認することが重要だ。また、古い解決記録は一定期間が経過すると自動的に削除される機能も備わっている。

このようにrerereは、特に複数の開発者やAIエージェントが並行して作業し、同じファイルで繰り返し競合が発生するような環境で真価を発揮する。git worktreeのように、一つのリポジトリから複数の作業ツリーを作成し、それぞれでAIエージェントを動かすような開発環境では、rerereの記録はリポジトリ全体で共有されるため、一度解決した競合が異なる作業ツリーやブランチでの作業にも適用され、開発効率が大幅に向上するだろう。これにより、AIエージェントによる開発のメリットを最大限に享受しつつ、競合解決の負担を軽減できる。