rerere — reuse recorded conflict resolutions
rerere (REuse REcorded REsolution) records how you resolved a conflict and auto-replays it when the same conflict reappears — a big win for long-lived branches rebased repeatedly. Enable with rerere.enabled true; resolutions live in .git/rr-cache. Review what it auto-applies.
You maintain a long-lived branch and rebase it onto main every few days. Each time, the same conflict in the same file shows up, and each time you resolve it the same way — by hand, again. It is tedious and error-prone busywork. Git has a feature built precisely for this: rerere, which watches how you resolve a conflict once and then replays that exact resolution automatically every future time the identical conflict appears.
By the end of this lesson you will be able to enable rerere, explain what it records and where, and describe both the time it saves and the silent-mistake risk you must guard against.
After this lesson you can explain what rerere (REuse REcorded REsolution) does, enable it, describe how it records and replays conflict resolutions from .git/rr-cache, name the workflows where it pays off, and state the risk of it silently re-applying a wrong resolution.
rerere stands for REuse REcorded REsolution. It is a built-in git mechanism that solves one specific pain: resolving the same merge conflict over and over. When on, git remembers the before-and-after of each conflict you resolve, keyed by the conflict’s content. The next time a conflict with the identical “before” shows up, git applies your remembered “after” automatically — you do the manual work once, not every time.
Turn it on with one config setting. rerere is off by default; enable it globally so it works across all your repos:
git config --global rerere.enabled trueFrom then on, every merge or rebase that hits a conflict feeds rerere: it records your resolution when you finish, and consults its cache when a new conflict appears. No change to how you run merge or rebase — it works quietly in the background.
Resolutions are stored in .git/rr-cache, keyed by conflict content. For each conflicting file, git stores a “preimage” (the conflict markers as git produced them) and, once you resolve it, a “postimage” (your resolution) under .git/rr-cache/<hash>/. The hash is derived from the conflict text, so matching is by content of the conflict, not by file path or commit — which is exactly why it can recognise “the same conflict” across a fresh rebase that produced new commit SHAs.
git rerere status # which files have a recorded preimage in this conflict
git rerere diff # what your in-progress resolution looks like vs. the preimageOn the next identical conflict, rerere auto-applies your past resolution. When a merge or rebase re-creates a conflict whose preimage matches a cached one, git writes your recorded postimage straight into the working file and tells you:
Resolved 'app/config.ts' using previous resolution.The conflict markers are already gone; the file holds your earlier answer. You still must git add the file and continue the merge/rebase — rerere resolves the content, it does not commit for you. If you got a resolution wrong and want to discard the memory for the current conflict, git rerere forget <path> drops it so you can resolve afresh.
▸Why this works
Where rerere truly pays off is long-lived branches and repeated integrations. A feature branch that lives for weeks and is rebased onto main repeatedly will replay the same conflicts on every rebase; rerere collapses that to one manual resolution. The same applies to maintainers who test-merge many topic branches together, drop the test merge, and re-merge later — a workflow Git’s own maintainers use. Anywhere the same divergence is reconciled more than once, rerere turns N manual resolutions into one.
The risk: it can silently re-apply a wrong past resolution — always review. rerere is only as right as the resolution you taught it. If you once resolved a conflict incorrectly, it will confidently re-apply that same mistake the next time, with no prompt — and because the markers vanish, it is easy not to notice. Treat an auto-resolved file as a claim to verify, not a finished answer:
git diff # inspect every rerere-resolved file before staging
git rerere forget <path> # discard a bad recorded resolution and redo it by handThe convenience is real, but a silently re-applied bad merge is a nasty bug; the discipline of reviewing the result is what makes rerere safe.
A weekly rebase that stops repeating itself.
You enable the feature and start a long-running branch:
git config --global rerere.enabled true
git switch -c feature
# ...weeks of work; main keeps advancing...
git rebase main
# CONFLICT in app/config.ts — you resolve it carefully
git add app/config.ts
git rebase --continueBehind the scenes, rerere saved the preimage and your postimage in .git/rr-cache. A few days later, main has moved again and you rebase once more:
git rebase main
# Resolved 'app/config.ts' using previous resolution.
git rerere diff # confirm the auto-applied result is what you intended
git diff # review it like any change before trusting it
git add app/config.ts && git rebase --continueThe conflict you would have hand-resolved a second (and third, and fourth) time was applied for you in an instant. You still review and stage it — but the repetitive judgement call only happened once. Had your original resolution been wrong, the same wrong content would reappear here, which is exactly why the git diff review step is not optional; git rerere forget app/config.ts would let you start that file’s resolution over.
▸Common mistake
A subtle misconception is that rerere “remembers conflicts per file or per branch.” It keys on the content of the conflict (the preimage hash), not on the path or the branch. So a slightly different surrounding context produces a different preimage and rerere will not match it — you will resolve again. Conversely, the identical conflicting hunk in a different file can match. This content-keying is what lets it survive rebases that rewrite SHAs, but it also means small upstream changes can quietly stop it from kicking in.
What does enabling rerere actually do for you?
rerere — REuse REcorded REsolution — records how you resolve a merge conflict and auto-replays that resolution whenever the identical conflict reappears, saving you from re-doing the same work on every rebase. Enable it with git config --global rerere.enabled true; resolutions live in .git/rr-cache, keyed by the conflict’s content (which is why it survives SHA-rewriting rebases). It shines on long-lived branches and repeated integrations, inspected via git rerere status/diff and reset per-file with git rerere forget. The catch: it can silently re-apply a wrong past resolution, so always git diff an auto-resolved file before trusting it. With this you have seen git from the object store up to the tools that automate its hardest day-to-day chore.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.