Rerere stands for “reuse recorded resolution.” It’s an optional Git feature that, once enabled, records the exact state of a merge conflict alongside how you resolved it, and then automatically applies that same resolution the next time Git encounters an identical conflict — without you needing to manually intervene again.

Picture a concrete, common scenario: a developer named Fatima maintains a long-lived feature branch that she rebases against main every single day, for several weeks, while the feature is being built. Each day’s rebase reintroduces the same conflict in a particular configuration file, because main and her branch both keep touching a shared section in incompatible ways. The first day, she resolves it manually, carefully merging both sides’ intent. With rerere enabled, every subsequent day’s rebase automatically reapplies that exact same resolution the instant the identical conflict reappears — turning what would be weeks of repetitive manual work into a single, one-time effort.

Certain Git workflows are structurally prone to repeated, identical conflicts. Long-lived feature branches that get rebased frequently against an actively changing main branch are the classic case — every rebase replays the branch’s commits one at a time against the new base, and if a particular commit’s change conflicts with something on main, that exact same conflict will resurface at that exact same commit on every single subsequent rebase, until the feature branch is finally merged or the underlying conflict source changes.

Before rerere, this meant genuinely redundant, tedious manual work — a developer might resolve the identical conflict dozens of times across the life of one feature branch. Rerere exists specifically to recognize and eliminate this redundancy, treating “I’ve already solved this exact problem” as valuable, reusable information rather than something to be manually redone from scratch every time.

You may likeWhat Is the Reflog?→

To understand rerere’s value fully, it helps to walk through exactly why the same conflict recurs mechanically during repeated rebasing, rather than assuming it’s simply bad luck.

This cycle can repeat for as many times as the branch is rebased before finally merging, with the conflict essentially identical each time, since it originates from the same unchanged commit on the feature branch colliding with the same unchanged surrounding content, however many times main itself has moved on since.

Rerere’s internal machinery is intentionally lightweight, built from a small set of local components.

Everything rerere maintains lives entirely inside the local repository’s own data, similar in spirit to the reflog — it’s a personal, local memory of resolutions, not something inherently shared with collaborators unless a team deliberately sets it up to be.

Here’s the precise sequence rerere follows, from a conflict first appearing to a matching conflict being automatically resolved later.

flowchart TD
    A["Merge/rebase produces\na conflict"] --> B{"Rerere has a matching\nrecorded signature?"}
    B -->|"No match found"| C["Conflict markers shown\nDeveloper resolves manually"]
    C --> D["Resolution staged"]
    D --> E["Rerere records signature\n+ resolution together"]
    B -->|"Match found"| F["Rerere auto-applies\nrecorded resolution"]
    F --> G["Developer reviews\nand confirms result"]
    E --> H["Cache grows,\nready for next occurrence"]
    

This diagram highlights the feature’s essentially self-reinforcing nature: the very first time through, a developer does the exact same manual work they’d always have done — the only difference is that rerere is quietly watching and learning. Every subsequent identical occurrence then takes that learned shortcut instead.

It’s worth being precise about what rerere actually automates, versus what still requires the same human judgment it always did.

Understanding exactly what rerere’s matching is based on clarifies both its power and its limits.

• The signature is based on the conflicting content itself, not the file’s identity. Rerere doesn’t care which file or which commit a conflict originated from — it matches purely on the shape of the conflicting text itself.
• This means the same conflict pattern can be recognized across genuinely different files. If two entirely unrelated files happen to produce an identical conflict pattern, rerere will apply the same recorded resolution to both, for better or worse.
• Only the conflicting region is stored, not the entire file. Rerere’s cache is deliberately narrow and focused, storing just the specific conflicting hunk and its resolution, not full file snapshots.
• A resolution is stored only once it’s actually confirmed. The recording happens when the developer stages the resolved result, not merely when they begin editing — an abandoned or incomplete resolution attempt isn’t captured.

Because rerere automates something as consequential as conflict resolution, understanding exactly where its reliability guarantees hold — and where they don’t — is essential.

• It’s reliable specifically because it never guesses. Rerere only ever applies a resolution that a human explicitly confirmed for an identically-shaped conflict — it has no independent logic for resolving anything it hasn’t genuinely seen before.
• Reliability weakens if the underlying situation has meaningfully changed, even with an identical conflict shape. A resolution that was correct in one surrounding context might not remain correct if the broader code around it has since evolved substantially, even though the specific conflicting hunk still matches.
• The cache can grow stale over a long project lifetime. Old recorded resolutions for conflict patterns that are no longer relevant simply sit unused, taking up a small amount of local storage without causing harm.
• Auto-resolution doesn’t mean auto-commit. Rerere fills in the resolved content, but the developer still explicitly reviews and completes the merge or rebase — it’s a shortcut for the tedious part, not a fully invisible, unreviewable automatic action.

Rerere’s local-by-default nature, and the option to share its cache, both carry meaningful implications worth understanding.

• By default, rerere’s memory is entirely local and personal. One developer’s recorded resolutions don’t automatically reach anyone else’s machine, meaning teammates facing the exact same recurring conflict won’t benefit from someone else’s earlier resolution unless the cache is deliberately shared.
• Sharing a rerere cache across a team requires deliberate setup. Some teams choose to version-control the rerere cache itself, letting the whole team benefit from a colleague’s earlier resolution of a shared, recurring conflict.
• A shared cache is only as trustworthy as the resolutions recorded into it. If an incorrect resolution was ever recorded and shared, that same incorrect result would now be silently, automatically reapplied for every teammate who encounters the matching conflict.
• No secrets or unrelated data are exposed through the mechanism itself. Rerere’s cache stores only the specific conflicting content and its resolution — it isn’t a general-purpose data exposure risk beyond whatever was already present in the code being merged.

Because rerere acts somewhat invisibly once enabled, having visibility into what it’s doing — and having a way to review its work — matters for trusting it fully.

Forgetting a Specific Recorded Resolution

If a particular recorded resolution turns out to have been wrong, or is simply no longer appropriate, it can be explicitly removed from the cache, preventing it from being auto-applied again in the future.

You may likeWhat Is Git Bisect?→

• Enable rerere specifically for workflows prone to repeated conflicts. It provides the most value precisely where long-lived branches are rebased frequently against a shared, actively evolving base.
• Resolve the first occurrence of any conflict with real care. Since that resolution becomes the template for every future automatic replay, getting it right the first time matters more than usual.
• Still glance over auto-applied resolutions before finalizing. A quick review preserves the safety net for the rare case where a matching conflict shape no longer represents the correct answer in its new context.
• Deliberately forget incorrect recorded resolutions. If a past resolution turns out to have been wrong, remove it from the cache rather than letting it keep silently reapplying itself.
• Consider a shared cache carefully, with review, for team-wide recurring conflicts. The benefit of shared learning is real, but only if what gets shared has actually been vetted as correct.

A subtler mistake worth naming directly: assuming rerere’s silence means nothing happened. Because a matched conflict is resolved automatically and often quickly, it’s easy for a busy developer to simply not notice that a shortcut was taken at all — building the habit of briefly checking what rerere touched, even when everything feels routine, is what keeps the feature’s real convenience from quietly becoming a blind spot.