Stop Re-Resolving the Same Git Conflicts with rerere

How Git's rerere feature remembers and automatically reapplies your conflict resolutions.

We've all been there. You're working on a long-lived feature branch, and you periodically merge or rebase from main to stay up-to-date. You hit a nasty merge conflict, spend ten minutes resolving it, and continue. A few days later, you rebase again, and the exact same conflict appears.

The Problem: Resolving the same conflict over and over again is frustrating, tedious, and feels like wasted time.

Quick Summary:

rerere stands for "reuse recorded resolutions" and remembers how you solved merge conflicts
Enable it once: git config --global rerere.enabled true
It automatically reapplies your previous conflict resolutions
Only works when the exact same conflict appears again (same file state)

Today I learned about a built-in Git feature designed to solve this exact problem: rerere.

What is rerere?

The name stands for "reuse recorded resolutions."

Think of it as muscle memory for merge conflicts.

Once enabled, it watches you resolve a conflict once, records how you did it, and then automatically resolves that exact same conflict for you every time it appears in the future.

How Does it Work?

The process is wonderfully simple and happens in the background.

How it works (3 steps):

1. Record Preimage
The first time you encounter a conflict in a file, rerere records the "preimage"—a snapshot of the conflicting state with all the conflict markers.

Recorded preimage for 'config.js'

2. Record Postimage
You then manually edit the file to fix the conflict. When you stage that file with git add, rerere records the "postimage"—the final, resolved version.

3. Reuse Resolution
The next time Git encounters the exact same preimage, rerere kicks in and automatically applies your saved postimage.

Resolved 'config.js' using previous resolution.

The file is resolved automatically. No manual editing required.

A Quick Example

Imagine you have a file config.js with a PORT number.

The Initial Conflict

You're merging a branch, and config.js gets a conflict:

First time seeing this conflict:

// config.js
<<<<<<< HEAD
const PORT = 3000;
=======
const PORT = 8080; // Changed by feature branch
>>>>>>> feature/new-api

You decide to keep 3000, so you edit the file to:

const PORT = 3000;

When you run git add config.js, rerere silently records this solution.

The Same Conflict, Later

A few days later, you rebase your feature branch. Git tries to apply the same commit that changed PORT to 8080, and it conflicts again.

But this time, rerere recognizes the exact same conflict block.

It automatically applies your previous resolution. Your config.js file is set to const PORT = 3000; without any manual intervention. ✨

What Does "Same Conflict" Mean?

This is the most important part to understand. rerere is very precise and fingerprints the entire conflict state of a file, not individual conflict hunks.

This means:

Scenario	Initial Conflicts	Later Conflicts	Will rerere Work?	Why?
Scenario A	Lines 10 and 50	Lines 10 and 50	Yes	Exact same conflict fingerprint
Scenario B	Lines 10 and 50	Line 10 only	No	Different preimage (missing conflict)
Scenario C	Lines 10 and 50	Lines 10, 50, and 100	No	Different preimage (additional conflict)

Key takeaway: It's "all or nothing" for the entire file. The conflict fingerprint must match exactly.

How to Enable It

It's not on by default. To turn it on globally for all your repositories:

One-time setup:

git config --global rerere.enabled true

That's it! Set it and forget it. It will start recording resolutions from your very next conflict.

The Takeaway

rerere is a massive time-saver for anyone who does frequent rebasing or manages long-lived branches. It's one of those simple config changes you make once that will save you countless moments of frustration down the line.

Want to see what resolutions rerere has saved? Check the .git/rr-cache/ directory in your repository. Each subdirectory contains a preimage and postimage of a conflict resolution.