git rerere: what every Git & GitHub developer should know

Introduction

Conflict resolution during a rebase or merge can feel repetitive. You resolve the same conflict in the same way across multiple commits, only to encounter it again in the next feature branch. This is where git rerere: what every Git & GitHub developer should know becomes invaluable. It's a built-in Git feature that records how you resolved a conflict and automatically applies that resolution the next time Git encounters the same conflict. For teams managing long rebases, complex merges, or parallel feature development, rerere transforms conflict resolution from a tedious manual process into an automated workflow.

What is rerere?

Rerere stands for "reuse recorded resolution." It's a Git mechanism that:

• Records the state of a conflicted file before you resolve it
• Stores your resolution in a special database
• Automatically applies that same resolution when an identical conflict appears later
• Works across different branches, rebases, and merges within the same repository

Think of it as Git's memory for conflict patterns. Once you've resolved a particular conflict in a particular way, Git learns it. The next time that exact conflict scenario occurs, Git can handle it without asking you to resolve it manually again.

Enable with rerere.enabled true

Rerere is disabled by default in Git. To enable it for your repository, run:

git config rerere.enabled true

This sets the configuration in your local repository's .git/config file. If you want to enable rerere globally across all repositories on your machine, use the --global flag:

git config --global rerere.enabled true

Once enabled, Git automatically starts recording and reusing resolutions. There's no additional setup or manual intervention required. You can verify the setting with:

git config rerere.enabled

This will output true if rerere is active. It's good practice to discuss rerere adoption with your team before enabling it globally. Some teams prefer to keep it local until everyone understands how it works, while others enable it immediately to benefit from conflict resolution history.

Git remembers how you resolved a conflict

When rerere is enabled and you encounter a merge conflict, Git records it in the .git/rr-cache directory. Let's walk through a real scenario:

Imagine two developers are working on a configuration file. Developer A modifies the database connection string, and Developer B modifies the cache timeout value in the same section. When Developer B tries to merge or rebase onto the main branch after Developer A's changes land, a conflict occurs.

You resolve the conflict by keeping both changes—the new connection string and the new cache timeout. You stage the resolved file and complete the merge or rebase. At that moment, rerere stores:

• The original (conflicted) state of the file
• The version from your current branch (ours)
• The version from the branch being merged (theirs)
• Your final resolution

This data is stored as a hash-based record. The hash is generated from the conflicted sections, making it unique to that particular conflict pattern. Git essentially creates a "fingerprint" of the conflict.

You can inspect what rerere has learned by looking at the cache directory:

ls -la .git/rr-cache/

Each directory in this folder represents a recorded conflict. Inside are files like preimage (the original conflict), postimage (your resolution), and thisimage (metadata).

Applies it automatically next time

The real power of rerere emerges when that same conflict appears again. Suppose you're rebasing a feature branch onto a freshly updated main branch, and the same configuration file conflict occurs. Here's what happens:

• Git detects the conflict as it reapplies each commit
• It checks the rerere cache for a matching conflict pattern
• If found, Git automatically applies your recorded resolution
• The conflict is resolved without you having to manually edit the file

This is where rerere saves tremendous time. Instead of manually resolving the same conflict five times across five rebased commits, you resolve it once, and rerere handles the rest.

Let's see this in action. During a rebase with a known conflict:

git rebase main feature-branch

If rerere recognizes a conflict from your history, you'll see output like:

CONFLICT (content): Merge conflict in config.yml
Resolved 'config.yml' using previous resolution.
Continuing rebase...

That "Resolved using previous resolution" message is rerere at work. No manual conflict resolution, no git add, no stopping the rebase. It continues automatically, greatly speeding up the operation.

You can manually trigger rerere to resolve conflicts at any point with:

git rerere

This runs the rerere logic on all current conflicts without requiring a merge or rebase operation.

Great for long rebases

Long rebases are where rerere becomes genuinely transformative. Consider a feature branch that's been in development for two weeks while the main branch received dozens of commits. When you finally rebase onto main, you might face the same conflict repeatedly—perhaps in a schema migration file that was modified multiple times, or in a configuration file touched by several different commits.

Without rerere, you'd manually resolve that conflict every time it appears during the rebase. With a 50-commit feature branch, you might resolve the same conflict three or four times. Each resolution takes cognitive load and time.

With rerere enabled, you resolve it once in the first commit that triggers it. Every subsequent commit in the rebase applies that resolution automatically. The rebase progresses smoothly, and you're freed up to review other changes or investigate the reasons for conflicts.

Real-world example: a team maintaining a multi-service architecture uses a shared constants file. Different services modify different sections of this file on different branches. When rebasing a service's feature branch onto main, the constants file conflicts appear repeatedly across commits. Rerere resolves it once and remembers it for all subsequent occurrences during that rebase—and future rebases too.

There's also a configuration option to ensure rerere doesn't get lost. You can set:

git config rerere.autoupdate true

This tells Git to automatically stage rerere's resolutions, so you don't have to manually git add them. Combined with rerere.enabled, this creates a nearly hands-free conflict resolution experience during long rebases.

Common mistakes

Trusting rerere blindly: Rerere is accurate for identical conflict patterns, but conflicts that look similar aren't necessarily the same. Always review auto-resolved files, especially in critical code paths. Don't assume rerere's solution is correct just because it was automated.

Forgetting to commit the rerere cache: The .git/rr-cache directory is local to your repository. If you want your team to benefit from recorded resolutions, you need to commit it. Add .git/rr-cache to your .gitignore (which is default) if you want to keep it private, or manage it separately if sharing is desired.

Using rerere without understanding what it resolved: If you enable rerere.autoupdate, resolutions happen silently during rebases. You might complete a rebase without noticing that a conflict was resolved automatically. Always review the rebase results before force-pushing.

Relying on rerere to fix design problems: If you're encountering the same conflict repeatedly, it might signal a deeper architectural issue—perhaps files are too tightly coupled, or branch strategies need rethinking. Use rerere to manage symptoms, but address root causes separately.

Neglecting the rerere cache over time: The cache can grow large if not maintained. Periodically review and clean up old resolutions with git rerere gc (garbage collection).

Key takeaways

• Enable rerere with git config rerere.enabled true to start recording and reusing conflict resolutions
• Rerere stores the conflicted state, both versions, and your resolution, creating a fingerprint for future matching
• Automatic resolution during merges and rebases saves time and reduces manual conflict handling
• Long rebases benefit dramatically from rerere—repeated conflicts are resolved once and remembered
• Always review auto-resolved files to ensure correctness; rerere is a tool, not a guarantee
• Combine with rerere.autoupdate true for a fully automated experience, but stay vigilant
• Discuss rerere adoption with your team to ensure everyone understands the workflow
• Use rerere to manage frequent conflicts, but investigate and address underlying design issues