Long-lived work sometimes meets the same conflict more than once. You resolve it during a trial merge, restart the work and encounter the identical disagreement again. Git rerere, short for reuse recorded resolution, can remember the earlier resolution and apply it to a matching conflict. That saves repetition, but a reused edit still needs review and tests. This guide keeps automatic index updates disabled so you can see the difference between a resolved working file and a staged resolution.
Understand what rerere records
Rerere records a conflicted state and the resolution produced for it. Git's merge and rebase workflows can invoke it when enabled, and Git notices the resolved content as the operation progresses. The mechanism recognizes corresponding conflict content rather than deciding what your program should mean. It cannot infer that a previous business rule is still appropriate after an API or requirement changes. Treat the saved resolution as a useful candidate edit whose correctness depends on the current context.
Enable rerere before the conflict you want it to remember. A completed conflict from the distant past is not automatically reconstructed just because the setting is enabled today. Local recorded resolutions live in the repository's rerere cache; this lesson does not assume teammates receive that cache when they clone. Document whether your team uses the feature, but do not rely on it as a hidden prerequisite for reproducing a merge. The actual merged commit should stand on its own as reviewed project history.
Separate a working resolution from index approval
rerere.enabled turns recording and reuse on. rerere.autoupdate controls whether a successfully reused resolution is also applied to the index. In this guide, autoupdate is false. That means a working file can contain the remembered resolution while the index still has unmerged entries. This visible pause is useful for learning and for workflows that require a person to approve the reused result before staging it.
Inspect the working diff, read the complete affected code and run relevant tests. Then git add the intended resolution and continue the merge or rebase using the command appropriate to that operation. Do not interpret the absence of conflict markers in the working file as proof that the index is resolved. git status and git ls-files -u answer different questions from simply opening the file. Keeping those states separate makes rerere behavior less mysterious when Git still reports an unfinished merge.
Use the inspection and repair commands
git rerere status lists paths whose conflict resolutions are being recorded. git rerere diff shows the current differences involved in recorded resolution work, and remaining helps identify conflicts that have not been autoresolved. These are inspection tools, not a substitute for the ordinary repository status and the project's tests. Their output depends on whether a conflict is active, so an empty listing after a completed merge is not evidence that the cache never recorded anything.
If a remembered resolution is wrong for the active conflict, use the documented forget operation for the affected path and resolve it correctly. Check the working state before doing that, because recreating or forgetting a conflict resolution is part of an active operation. Do not clear every recorded resolution reflexively when only one path needs attention. Rerere's cache management commands have distinct purposes, and Git may clean older entries over time. Focus first on getting the current merge correct and reviewable.
Reuse only after checking the new context
A repeated conflict can occur during a trial merge, a rebase iteration or an integration branch rebuild. Reusing an edit reduces typing, but the surrounding code may have changed enough that the old choice no longer satisfies the project. For example, combining two configuration values might have been valid before a schema change and invalid afterward. Review semantic meaning even when the conflict's textual shape is familiar.
The lab deliberately resets a disposable branch to recreate the same conflict. That reset is a demonstration technique, not an instruction to replace shared history. On a real branch, preserve unrelated work and use the appropriate operation controls. If you want to compare a reused resolution with a manual alternative, do so in a separate worktree or temporary branch whose role you understand. The final outcome should be a normal reviewed commit with tests and clear intent, independent of whether rerere helped prepare it.
Sources and prerequisites
Complete merge conflicts, merging and rebase first. The official rerere reference and configuration reference define recording, reuse and index-update behavior.
Reuse Git Conflict Resolutions with Rerere Summary
- Enable rerere before the conflicts you want to record.
- A reused working file and a resolved index are distinct states.
- Review and test the current resolution even when Git remembers its text.
Reuse Git Conflict Resolutions with Rerere Examples
Each example shows the code, the output it produces and what each part does.
Repeat a conflict and inspect a reused resolution
Run this complete Bash sequence only in a new lab directory. The two branches replace the same line differently. The first merge records a combined resolution; resetting the lab's merge commit lets the second merge encounter the same conflict. The expected output shows the reused working content while the index remains unmerged.
Both merge attempts report a conflict, and rerere reports recording or reuse as appropriate. The final file has the remembered text. The index still contains unmerged stages because autoupdate is disabled. Read and approve this candidate resolution before staging it.
mkdir rerere-lab
cd rerere-lab
git init -b main
git config user.name Learner
git config user.email learner@example.test
git config rerere.enabled true
git config rerere.autoupdate false
printf 'base\n' > choice.txt
git add choice.txt
git commit -m 'Base choice'
git switch -c topic
printf 'topic\n' > choice.txt
git commit -am 'Topic choice'
git switch main
printf 'main\n' > choice.txt
git commit -am 'Main choice'
git merge topic || true
printf 'main and topic\n' > choice.txt
git add choice.txt
git commit -m 'Combine choices'
git reset --hard HEAD~1
git merge topic || true
cat choice.txt
if test -n "$(git ls-files -u)"; then echo 'index still unmerged'; fimain and topic
index still unmergedReuse Git Conflict Resolutions with Rerere in Real Projects
Finish a merge with a reused resolution
Continue in rerere-lab. Review the reused file, stage it and finish the merge. The tiny fixture has no application tests, so the direct content assertion below is its meaningful check. In a real project, use tests that exercise the behavior affected by the conflict.
test "$(cat choice.txt)" = 'main and topic'
git add choice.txt
git commit -m 'Approve reused resolution'
git log -1 --format='%s'
if test -z "$(git ls-files -u)"; then echo 'index resolved'; fiApprove reused resolution
index resolvedThe new merge commit records the approved tree. Rerere saved the repetitive edit, while the explicit assertion and staging step made the review boundary visible. A normal clean repository status now replaces the active conflict state.
Reuse Git Conflict Resolutions with Rerere FAQ
Why does Git still report a conflict after rerere fixed the file?
With rerere.autoupdate disabled, successful reuse updates the working file but leaves the index's unmerged entries for explicit review. Inspect the result, run relevant checks and stage the intended resolution. Then continue the active merge or rebase. This behavior is deliberate: a remembered textual resolution is a candidate, while staging records your approval of the version that the repository operation will use.
Does rerere know whether my old resolution is logically correct?
No. It recognizes and reuses recorded conflict resolutions; it does not evaluate business rules or execute your test suite. A resolution that was correct earlier may be wrong under new surrounding code or requirements. Read the affected behavior and run focused tests every time. The tool is most useful when it removes repeated mechanical editing while the reviewer still owns the semantic decision.
Will a teammate receive my rerere cache when cloning?
Ordinary repository cloning transfers referenced Git history, not an assumption that your local rerere cache is part of the project. A teammate can enable the feature and build their own recorded resolutions through their workflow. If a team adopts a separate cache-sharing process, document and review that process explicitly. The committed merge result should remain understandable and reproducible without relying on invisible local cache state.
What if a reused resolution is wrong for the current conflict?
Pause the active operation and inspect the affected path. Git's rerere forget command can discard the recorded resolution for a current conflict so you can provide a new one. Follow the documented procedure for restoring the conflict state when needed, then resolve, stage and test the intended content. Avoid clearing unrelated cache entries or continuing automatically just because the file no longer contains markers.
Reuse Git Conflict Resolutions with Rerere Exercises
Answer each one and check it instantly. If you get stuck, open the hint before the answer.
After the second merge in the lab, why does git ls-files -u still list entries?
Reuse Git Conflict Resolutions with Rerere Quiz
2 questions to check what you learned.
What should happen before accepting a remembered conflict resolution?
- Assume the older decision is always valid
- Review its current meaning and run relevant checks
- Delete the branch containing the other side
When is enabling rerere most useful for recording a new resolution?
- Only after deleting the repository
- Only after every historical conflict is complete
- Before encountering and resolving the conflict