Multi-Agent Parallel Development: Solve a Git Conflict Once with rerere

When Claude Code and Codex modify the same file on two branches at the same time, a merge conflict is almost inevitable. Worse, the same conflict shows up once during a trial merge, and again when you land the first agent and rebase the second. Git's rerere feature exists exactly for this: record a conflict resolution once, then replay it automatically.

The Problem: One Line of Code, Two Manual Resolutions

Suppose you assign Claude Code a bug in the login module and give Codex the task of tidying up the authentication logic. Each agent works on its own branch and finishes its changes. You first merge both into a temporary branch to run tests, and a guard clause in src/login.js conflicts. You read both versions, write the line that preserves both fixes, and the tests pass.

Then you properly land the first agent and rebase the second onto main. Same file, same line, same conflict—and you resolve it by hand all over again. If an agent touches that branch once more before final landing, you might have to resolve it a third time. According to Git's official docs (Pro Git and the git-rerere manual), git rerere—short for "reuse recorded resolution"—was built specifically for this kind of repeated conflict.

What is a Git worktree

git worktree lets you check out multiple working trees from the same repository. Each working tree maps to an independent branch but shares the underlying .git directory (including the object database, refs, config, and hooks). This means you can have full working copies of hermes/fix-login and hermes/tidy-auth at the same time in directories like ../fix-login and ../tidy-auth, without repeatedly running git checkout to switch back and forth. For multiple coding agents running in parallel, this is essential: Claude Code and Codex each work in a separate worktree without disturbing each other's staging area or working directory, yet all their commits go into the same repository history. And because .git is shared, rerere's rr-cache and rerere.enabled configuration are shared across all worktrees.

Enabling rerere: Configure Once, Automatic from Then On

Setup takes just one command:

git config rerere.enabled true

Git's official docs note that git merge runs rerere automatically when an automatic merge fails, and git commit runs it again when committing the merge result. You don't need to invoke it manually in the normal flow. Also, if an rr-cache directory already exists in the repository, Git enables the feature by default (see the Git config reference).

Here's a hands-on demo: create a repository and an initial file, then create an independent branch and worktree for each agent:

git worktree add -q -b hermes/fix-login ../fix-login
git worktree add -q -b hermes/tidy-auth ../tidy-auth

The first agent rejects empty passwords, the second trims usernames—and both change the same line of code. Do a trial merge in a temporary worktree:

git worktree add -q -b try-both ../try-both main
cd ../try-both
git merge -q hermes/fix-login
git merge hermes/tidy-auth

The second merge triggers CONFLICT (content), and Git prints a line starting with Recorded preimage for. After resolving the conflict manually, you can use two subcommands before committing to check what rerere will remember:

git rerere status   # paths whose resolutions will be recorded
git rerere diff     # comparison between the conflicted version and your current edits

On commit, Git prints Recorded resolution for. This branch is already the merge result of both agents' work—run your tests here.

The structure of rr-cache and the preimage/image concept

For each conflict, rerere creates a directory under .git/rr-cache/ named after the conflict's hash, containing three key files: preimage (the original content with conflict markers before resolution), postimage (the content after you resolved it manually), and thisimage (the conflicted version encountered this time). When rerere detects a new conflict, it computes a normalized hash of the conflict hunk—deliberately stripping out line numbers and some context-irrelevant information, based only on the conflict's "content shape"—then looks for a matching directory in rr-cache. On a hit, it writes the recorded postimage directly into the working file; on a miss, after you resolve and commit, it stores the current resolution as a new entry. Understanding this mechanism explains the two limitations emphasized in this article: why it "only matches exactly identical conflict hunks" (the hash must match), and why it "only compares text" (the hash doesn't encode semantics).

After Landing the First Agent, rebase Replays Automatically

The trial merge is only for testing. For the actual landing, merge the first agent into main, then rebase from the second agent's own worktree:

cd ../rerere-demo
git merge -q hermes/fix-login
cd ../tidy-auth
git rebase main

The rebase hits the same conflict, but this time Git prints Resolved 'src/login.js' using previous resolution., and the file already contains the merged line. As described in the Pro Git chapter, this is exactly the flow: resolve a merge manually once, then let rerere fill in the resolution during rebase.

It's worth noting what rerere does not do. The official docs explicitly say it "leaves the index file alone"—the path is still considered conflicted, and rebase still pauses. You need to inspect, stage, and continue:

git diff                  # inspect what rerere wrote
git add src/login.js
GIT_EDITOR=true git rebase --continue

There's a rerere.autoUpdate setting that stages replayed files automatically, but it defaults to false. The Git rebase docs describe --no-rerere-autoupdate as "a good way to double-check what git-rerere did and catch potential mismerges." When you're dealing with code written by two agents—code you didn't type yourself—that extra check is well worth one more git add.

When the Recorded Resolution Is Wrong

rerere replays anything you've recorded, including mistakes. Suppose during the trial merge you kept the trimmed username but dropped the password check—rerere will write that mistake back every time the same conflict occurs.

The fix is to discard the record and rebuild the conflict markers while the rebase is paused at the conflict:

git rerere forget src/login.js
git checkout --conflict=merge src/login.js

**Why `git checkout --conflict=merge` restores the conflict**

When a conflict occurs, Git stores three stage entries in the index for each conflicted path: stage 1 is the common ancestor version, stage 2 is the current branch version, and stage 3 is the branch being merged. Even after you resolve the conflict and write the merged content, as long as you haven't run `git add`, those three stage entries typically still exist. `git checkout --conflict=merge` (equivalent to the default style outside `--conflict=diff3`) reads those index stages and regenerates the file with `<<<<<<<`, `=======`, and `>>>>>>>` markers, returning the working tree to the unresolved-conflict state. That's why, after rerere has replayed a wrong resolution, this command combined with `git rerere forget` lets you "start over": `forget` clears the bad record, `checkout` rebuilds the markers, you manually write the correct line, and then `git rerere` records the new resolution.
# After manually fixing the file:
git rerere
git add src/login.js
GIT_EDITOR=true git rebase --continue

forget resets rerere's recorded resolution for the current conflict, and git checkout --conflict=merge regenerates the conflicted file with markers.

A few limitations to know before you use it:

• It only matches exactly identical conflict hunks. If an agent rewrites that line's version, the conflict is new and needs to be resolved again.
• It only compares text. The replayed resolution may be wrong for code that has changed elsewhere—run tests after every replay.
• git rerere gc cleans up old records: unresolved ones after 15 days, resolved ones after 60 days, controlled by the gc.rerereUnresolved and gc.rerereResolved configs. If agent branches live longer, bump these values up.
• It identifies conflicts by their conflict markers. Lines in the file that already resemble <<<<<<< can confuse it; the official docs point to the conflict-marker-size attribute as the solution.

The Collaborative Value of rerere in Multi-Worktree Environments

In desktop apps like Hermes IDE that run Claude Code and Codex in parallel, rerere's advantages become even more pronounced. According to Git's repository layout docs, all worktrees of the same repository share one .git directory, and rerere's rr-cache where records are stored is marked as a shared directory—the repository config is shared too.

This means a single git config rerere.enabled true is enough, and a conflict resolved in one task worktree can be replayed in any other worktree. In the demo, you recorded the resolution in ../try-both, and Git replayed it in ../tidy-auth.

The overall flow matches the command line: land the first task (either a local merge or fetching the base branch after a PR merge) so the base branch includes the first agent's changes; from the second task's worktree terminal, rebase its branch onto that branch, and rerere automatically fills in the resolved line; review the file, git add, run git rebase --continue, then land the second task.

The same applies if you let an agent perform the rebase—since rerere's records and config live in the repository, the agent's git rebase main will read the recorded resolutions just as your manual run would.

Key Takeaways

Two agents, two branches is the simplest multi-agent setup, yet it already produces repeated conflicts. git rerere reduces manual conflict resolutions from three to one by recording once and replaying automatically. In multi-worktree parallel development environments, this feature goes from "nice to have" to "infrastructure."

One-line Summary

git rerere records a conflict resolution once and cuts repeated manual conflict handling from three times to one in multi-agent parallel development.

Paragraph Summary

When Claude Code and Codex modify the same file on separate branches, the same merge conflict keeps recurring during trial merges, final landings, and rebases. With git config rerere.enabled true, Git records the conflict's preimage when automatic merge fails, saves the postimage after you resolve and commit manually, and automatically replays it when the exact same conflict hunk appears again. Because all worktrees of the same repository share the .git directory, rr-cache and the config take effect globally—which is why this feature goes from nice-to-have to infrastructure in multi-agent parallel scenarios. But rerere only compares text, only matches identical conflict hunks, and doesn't auto-stage results, so you should git diff and run tests after every replay.