git rerere: Reuse Recorded Resolution for Repeated Merge Conflicts

Anyone who has repeatedly rebased a long-running feature branch (Module 7) against a fast-moving main branch knows the frustration of resolving the *exact same* conflict, in the exact same file, over and over with each new rebase attempt. `git rerere` — 'Reuse Recorded Resolution' — exists specifically to eliminate this repetitive, wasteful work.

Learning Objectives

• Explain what git rerere records and how it recognizes a recurring conflict.
• Enable rerere and observe it recording a conflict resolution automatically.
• Understand how rerere automatically applies a previously recorded resolution.
• Use git rerere forget to discard an incorrect recorded resolution.

Key Terms to Know Before Using git rerere

• git rerere: A Git feature ('Reuse Recorded Resolution') that remembers how a specific conflict was resolved and automatically reapplies that same resolution if the identical conflict recurs.
• rerere cache: The local storage where rerere records a conflict's 'before' state and its resolution, keyed by the specific content of the conflicting sections.
• git rerere forget <file>: Discards a previously recorded resolution for a file, useful if a stored resolution turns out to have been incorrect.

How git rerere Actually Works

The classic scenario `rerere` addresses: you're working on a long-running feature branch, and periodically rebase it (Module 7) onto an actively changing `main` branch to stay current. Each time you rebase, if both branches have touched the same specific lines, you get the **same conflict**, in the same file, requiring the **same resolution** — over and over, once per rebase attempt, purely because rebasing replays commits and re-encounters the same underlying divergence each time.

`git rerere` (**Re**use **Re**corded **Re**solution) solves this by remembering exactly how you resolved a specific conflict the first time, and **automatically reapplying that exact same resolution** the next time Git encounters an identical conflict — no repeated manual work required.

Enabling it (a one-time setup, ideally global, so it applies everywhere):

```
git config --global rerere.enabled true
```

Once enabled, `rerere` works entirely automatically and transparently in the background:

1. The **first time** a specific conflict occurs (identified by the exact content of the conflicting sections, not the specific commit or file path), Git records the 'before' state (the conflict markers) into a local cache.
2. You resolve the conflict manually, exactly as you normally would.
3. `rerere` also records this **resolution**, associated with that specific conflict's 'before' state.
4. The **next time** Git encounters that exact same conflict again (for example, during another rebase attempt after `main` has moved further forward, but still touching the same overlapping lines) — `rerere` automatically applies the previously recorded resolution, without requiring you to manually resolve it again. You'll typically still want to review the automatically-applied resolution and explicitly stage/commit it, but the actual manual conflict-resolution work is skipped entirely.

This is genuinely valuable specifically in situations involving **repeated rebasing or repeated merging of the same two lines of history** — a long-lived feature branch rebased many times, or a pair of branches that get merged together repeatedly (some teams' release workflows do this routinely) — where the same underlying conflict would otherwise need to be manually resolved fresh every single time.

If a recorded resolution turns out to have been **incorrect** (perhaps the right fix has genuinely changed since it was first recorded), you can discard it:

```
git rerere forget <file>
```

This removes the specific recorded resolution for that file's conflict, so the next occurrence will require fresh, manual resolution again — at which point `rerere` will record the new, corrected resolution going forward.

A useful mental model connecting to this module's overall theme: `rerere` is, quite literally, Git's own recorded 'memory' of how you fixed something before, automatically applied the next time the identical problem recurs — a small, focused feature, but one that can save meaningful, repetitive manual effort for anyone dealing with a genuinely recurring conflict pattern.

git rerere Workflow: Visual Walkthrough

Draw a two-cycle timeline. CYCLE 1 (first occurrence): 'Rebase attempt #1' → 'CONFLICT in payment.js (specific lines X-Y)' → 'Manually resolve' → rerere silently records this resolution in its cache. CYCLE 2 (recurrence, e.g., after main moves further and you rebase again): 'Rebase attempt #2' → 'SAME CONFLICT recurs (identical content)' → rerere AUTOMATICALLY applies the recorded resolution — no manual work needed → 'Review + stage + continue.' Caption: 'rerere recognizes conflicts by their exact CONTENT, not by commit or file path specifically.'

git rerere Commands: Quick Reference Table

Command	Purpose
git config --global rerere.enabled true	Enables rerere globally, a one-time setup
(automatic) first conflict occurrence	Records the conflict's 'before' state and your manual resolution
(automatic) recurring identical conflict	Automatically reapplies the previously recorded resolution
git rerere forget <file>	Discards a specific recorded resolution, in case it was incorrect

git rerere: Command Syntax and Examples

# One-time setup: enable rerere globally
git config --global rerere.enabled true

# First occurrence of a conflict during a rebase
git rebase main
# CONFLICT (content): Merge conflict in payment.js
# (resolve manually, as usual)
vim payment.js   # fix the conflict
git add payment.js
git rebase --continue
# rerere has now silently recorded this resolution

# ... later, main has moved further forward, you rebase again ...
git rebase main
# CONFLICT (content): Merge conflict in payment.js   <- SAME underlying conflict
# Resolved 'payment.js' using previous resolution.    <- rerere applied it automatically!
git diff   # review the auto-applied resolution before proceeding
git add payment.js
git rebase --continue

# If a recorded resolution turns out to be wrong, discard it
git rerere forget payment.js

Breaking Down the git rerere Example

The first rebase attempt shows a completely normal, manual conflict resolution — nothing different from Module 7's rebase conflict handling, except that `rerere`, now enabled, silently records this resolution in the background. The second rebase attempt (occurring later, after `main` has advanced further, but still involving the exact same underlying conflicting content) shows `rerere`'s payoff directly in Git's own output: 'Resolved payment.js using previous resolution' — the conflict was automatically fixed using the recorded resolution, with no manual re-resolution required, though reviewing the result with `git diff` before staging and continuing remains a sensible habit. The final `git rerere forget` demonstrates discarding a specific recorded resolution if it's later found to be incorrect.

How git rerere Is Used on Real Engineering Teams

• Developers maintaining a long-lived feature branch that requires frequent rebasing against an actively developed main branch are the classic beneficiaries of rerere, since the same conflicts often recur across many successive rebase attempts.
• Some release engineering workflows that involve repeatedly merging the same pair of branches (like periodically merging a stable branch's hotfixes forward into an active development branch) rely on rerere to avoid manually re-resolving the same recurring conflicts each time.
• rerere is a relatively lesser-known Git feature compared to more commonly discussed commands, but experienced engineers who deal with genuinely repetitive conflict patterns often consider it a significant, underrated quality-of-life improvement once discovered.
• Some teams enable rerere by default across all their developers' machines (via a shared configuration setup) specifically for projects known to have long-lived branches with predictably recurring conflicts.

git rerere Interview Questions and Answers

Q1. What problem does git rerere solve?

It eliminates the need to manually resolve the exact same merge or rebase conflict repeatedly, which commonly happens when a long-lived feature branch is rebased multiple times against an actively changing main branch, encountering the same underlying conflict on each attempt.

Q2. How does rerere recognize that a conflict is 'the same' as one encountered before?

It identifies a conflict by the exact content of the conflicting sections (the 'before' state recorded in its cache), not by the specific commit hash or file path involved. This means it can recognize and reapply a resolution even across different rebase attempts, as long as the underlying conflicting content matches.

Q3. What would you do if a resolution rerere has recorded turns out to be incorrect?

Run git rerere forget <file>, which discards that specific recorded resolution. The next time the same conflict occurs, it will require fresh, manual resolution again, at which point rerere will record the new, corrected resolution for future use.

git rerere Quiz: Test Your Understanding

1. What does git rerere stand for, and what does it do?

1. Remove Redundant Repository — deletes duplicate objects
2. Reuse Recorded Resolution — remembers and automatically reapplies a previous conflict resolution
3. Rewrite Repository — rewrites commit history
4. Restore Remote Reference — fixes broken remote tracking

Answer: B. Reuse Recorded Resolution — remembers and automatically reapplies a previous conflict resolution

Explanation: rerere records how a specific conflict was manually resolved, and automatically applies that same resolution the next time an identical conflict is encountered, saving repetitive manual work.

2. In what situation is git rerere most genuinely useful?

1. Resolving a conflict for the very first time ever
2. Situations involving the SAME conflict recurring multiple times, such as repeatedly rebasing a long-lived branch
3. Creating a new repository
4. Tagging a release

Answer: B. Situations involving the SAME conflict recurring multiple times, such as repeatedly rebasing a long-lived branch

Explanation: rerere's value comes specifically from eliminating repeated manual resolution of an identical, recurring conflict, most commonly encountered when repeatedly rebasing or merging the same pair of diverged branches.

3. What does git rerere forget <file> do?

1. Permanently deletes the file
2. Discards a previously recorded resolution for that file's conflict
3. Disables rerere entirely for the whole repository
4. Forgets the file's entire commit history

Answer: B. Discards a previously recorded resolution for that file's conflict

Explanation: This command removes a specific recorded resolution, useful if it turns out to have been incorrect, requiring fresh manual resolution the next time that conflict is encountered.

Common git rerere Mistakes Beginners Make

• Not enabling rerere at all (it's off by default), missing out on its benefit entirely for a project with genuinely recurring conflicts.
• Blindly trusting an automatically applied rerere resolution without reviewing it, when the underlying situation may have subtly changed since the resolution was first recorded.
• Not knowing about git rerere forget, and instead manually working around an incorrect recorded resolution in a more roundabout way.
• Expecting rerere to help with genuinely novel, first-time conflicts — it only provides value once the same specific conflict has already been resolved and recorded once before.

git rerere: Exam-Ready Quick Notes

• git rerere ('Reuse Recorded Resolution'): remembers a conflict resolution and automatically reapplies it when the identical conflict recurs.
• Enable with: git config --global rerere.enabled true (off by default).
• Recognizes conflicts by their exact CONTENT, not commit hash or file path — works across different rebase/merge attempts.
• git rerere forget <file>: discards a specific recorded resolution if it was incorrect.

git rerere: Key Takeaways

• git rerere eliminates the repetitive frustration of manually resolving the exact same conflict multiple times, most commonly during repeated rebasing.
• It works by recognizing a conflict's exact content, automatically reapplying a previously recorded resolution the next time that same conflict recurs.
• It's a small, focused, somewhat underrated feature that provides real, meaningful value specifically for anyone dealing with genuinely repetitive conflict patterns.

Frequently Asked Questions About git rerere

Q1. What does git rerere do?

It remembers how you resolved a specific merge or rebase conflict, and automatically reapplies that same resolution the next time Git encounters the exact same conflict again, saving you from manually resolving it repeatedly.

Q2. How do I enable git rerere?

Run git config --global rerere.enabled true, a one-time setup that enables it for all your future Git operations, since it's off by default.

Q3. When is git rerere actually useful?

It's most valuable when the same conflict recurs multiple times, such as repeatedly rebasing a long-lived feature branch against an actively changing main branch, where the exact same lines conflict on each successive rebase attempt.

Q4. How does rerere know a conflict is 'the same' one it saw before?

It identifies conflicts based on the exact content of the conflicting sections themselves, not by commit hash or file path, which is why it can recognize and reapply a resolution even across entirely different rebase or merge attempts.

Q5. What if rerere automatically applies a resolution that turns out to be wrong?

Run git rerere forget <file> to discard that specific recorded resolution. The next time the conflict occurs, you'll need to resolve it manually again, and rerere will record the new, corrected resolution going forward.

Summary

`git rerere` ('Reuse Recorded Resolution') solves the frustrating, repetitive problem of manually resolving the exact same merge or rebase conflict multiple times — a common scenario when repeatedly rebasing a long-lived feature branch against an actively changing main branch. Once enabled with `git config --global rerere.enabled true` (it's off by default), rerere silently records a conflict's 'before' state and its manual resolution the first time it's encountered. The next time Git encounters that exact same conflict — recognized by the content of the conflicting sections, not the specific commit or file path — rerere automatically reapplies the previously recorded resolution, eliminating the need for repeated manual work, though reviewing the auto-applied result before staging and continuing remains a sensible habit. `git rerere forget <file>` discards a specific recorded resolution if it later turns out to have been incorrect, ensuring the next occurrence requires (and records) a fresh, corrected resolution.