What rerere does

Rerere — "reuse recorded resolution" — watches you resolve a merge conflict, records the resolution, and replays it the next time the same conflict appears. It is invaluable on long-lived branches that repeatedly rebase or merge against an active main, and on release branches that frequently re-merge feature branches.

Enabling

git config --global rerere.enabled true
git config --global rerere.autoupdate true

autoupdate stages the resolved hunks for you when rerere has a confident answer.

How it works

When a conflict occurs, Git stores a hash of the conflict context under .git/rr-cache/. After you resolve and commit, the resolution is associated with that hash. Future merges that produce the same conflict context get the recorded resolution applied automatically.

Inspecting state

git rerere status
git rerere diff
git rerere remaining

status lists files with conflicts, diff shows the recorded resolution against the current state, and remaining shows files still unresolved.

Forgetting a bad resolution

If you recorded the wrong resolution, clear it:

git rerere forget path/to/file

Next time the conflict appears, Git will not auto-apply, letting you resolve afresh.

Use case: rebase storms

You maintain a long feature branch and rebase against main weekly. The same conflicts in CHANGELOG.md appear every time. Without rerere you re-resolve them; with rerere, the first manual resolution is replayed for the rest of the rebase, often clearing out hundreds of conflicts in seconds.

Use case: integration branch

Some teams maintain an "integration" branch that re-merges all feature branches nightly to detect conflicts early. Rerere makes those nightly merges nearly hands-off after the first conflict day.

Common mistakes

Trusting rerere blindly: always inspect with git diff --staged before committing, especially when autoupdate is on. Rerere matches by conflict context, not semantic intent — a "correct" replay may still be wrong if the surrounding code has changed meaning. Sharing .git/rr-cache across the team is non-trivial; tools like git-rerere-train can help, but most teams let each developer build their own cache.

Training rerere from history

You can teach rerere from past merge resolutions:

git rev-list --merges main | while read merge; do
  git checkout "$merge^"
  git merge "$merge^2" || git rerere
  git reset --hard
done

Related

See "Merge conflict resolution in depth" and "Custom merge strategies and drivers".