Reuse Git Merge Conflicts Automatically with rerere

Resolving the same merge conflict for the third time this month is what git rerere exists to end, by remembering the fix and replaying it.

This guide enables it, walks through a safe test-merge workflow, and shows how to inspect, reject, forget and prune saved resolutions. It targets Git 2.43.0, the version installed here. Allow about 10 minutes for setup and a first supervised resolution.

Before you start

Use a Git working tree with a clean status, a topic branch, and a branch that regularly changes the same files. You do not need root privileges. Do not begin in a directory containing uncommitted work: the merge examples deliberately change the index and working tree.

Check the version and current state first:

git --version
git status --short

Expected output includes git version 2.43.0 on the reference system. A clean repository prints no lines for the second command. If it prints paths, commit or stash that work before continuing.

1. Enable recording

Enable rerere in the repository where you want the remembered resolutions. Repository-local configuration avoids touching unrelated projects:

git config rerere.enabled true
git config --local --get rerere.enabled

The second command should print true. The manpage requires rerere.enabled; without it, the ordinary git rerere command does not provide the recording workflow described here.

Git stores the records as repository metadata, normally below .git/rr-cache. Treat that directory as useful state, not as a file to edit by hand. It may contain text from your conflicts, so include it in your repository backup and access-control thinking.

2. Resolve the first conflict carefully

Start the merge or rebase that is likely to repeat:

git switch topic
git merge main

Replace topic and main with real branch names. A failed automerge causes Git to invoke rerere automatically, and if the conflict is new, the conflicted files get recorded. Inspect what rerere plans to record:

git rerere status
git rerere diff

status lists conflicted paths whose resolution will be recorded. diff displays changes in the current resolution state. Neither command decides the correct source code for you.

Edit each file and remove every conflict marker, then review both the worktree and the staged result before accepting it:

git diff
git diff --check
git add path/to/conflicted-file
git diff --cached
git commit

Use a real path in place of path/to/conflicted-file. The merge commit records the hand resolution, and Git also invokes rerere when committing a merge result.

Tip: run the project's tests before committing if it has them. A remembered resolution is only a previous answer, not proof the new context is correct.

3. Let rerere help with the next occurrence

When a later merge or rebase hits the same conflict, Git runs rerere as part of that operation. You can also run it explicitly:

git rerere
git rerere remaining

If the recorded resolution applies cleanly, rerere writes the result into the working tree. It leaves the index alone, so remaining reports paths whose conflicts have not been autoresolved, including conflicts such as submodules that rerere cannot track. Inspect the result, run tests, and stage only after you approve it:

git diff
git diff --check
git add path/to/resolved-file
git status --short

Checkpoint: a clean diff and an empty remaining result are useful signs, but neither replaces tests or a review.

If the resolution is wrong, edit it before staging. To abandon the operation, use the merge, rebase or am command's documented abort action; those abort actions automatically clear rerere's temporary merge metadata.

4. Fix a saved resolution that turns out wrong

Do not repeatedly accept a stale result. While the current conflict is present, forget the saved resolution for a path, then resolve it afresh:

git rerere forget -- path/to/conflicted-file

The pathspec sits after -- so a filename cannot be mistaken for an option.

Warning: this changes rerere metadata and cannot restore the discarded entry from the command itself, so use it only after checking the path. Re-run git rerere status, edit the conflict manually, inspect it, and stage it only when it is correct.

If you are abandoning the whole conflict instead, clear rerere's metadata for the operation:

git rerere clear

Normally git merge --abort, git rebase --abort or git am --abort handles this cleanup. Do not confuse clear with undoing a commit: it resets rerere metadata, not branch history.

5. Prune old records and avoid the failure traps

Rerere records depend on conflict markers. If ordinary file content contains lines that look like those markers, Git may fail to record a conflict correctly. The manpage points to the conflict-marker-size setting in .gitattributes as the workaround. Test it with the repository's actual merge tools before relying on automatic reuse.

Old records are pruned with:

git rerere gc

On Git 2.43.0, the defaults prune unresolved records older than 15 days and resolved records older than 60 days, controlled by gc.rerereUnresolved and gc.rerereResolved.

Warning: pruning removes old reusable data, so do not run it during an investigation where an older resolution might still be needed.

Done means