If you keep a long-lived branch - a big feature, a fork of a config file, a redesign - you know the ritual: merge main in, resolve the same conflict in the same file, again, every week. Git has a built-in answer almost nobody turns on: rerere, short for “reuse recorded resolution”.
One flag#
git config --global rerere.enabled true
From then on, whenever you resolve a conflict, Git quietly records what the conflict looked like and what you turned it into. The next time the same conflict appears - same file, same conflicting hunks - Git applies your recorded resolution automatically and tells you it did:
Resolved 'routes/web.php' using previous resolution.
You still review the result and commit it yourself; rerere never commits for you. It just skips the part where you re-derive a decision you already made.
Where it earns its keep#
- Long-lived feature branches that merge main regularly: the recurring conflicts stop recurring.
- Rebase-heavy workflows: a rebase replays commits one by one, so the same conflict can surface at several steps. With rerere, you solve it at the first step and the rest resolve themselves. This pairs well with the linear-history style from Merging vs Rebasing for Small Teams.
- Release branches that cherry-pick: cherry-picking a set of commits onto an older branch often hits conflicts similar to ones you resolved on main.
Trust, but verify#
Rerere matches conflicts by content, so it only replays when the conflict is genuinely the same - a different hunk still stops for you. Two commands keep it honest:
git rerere status # files with recorded resolutions in play
git rerere forget # drop a recorded resolution you no longer trust
And the normal safety nets still apply: run the tests after any auto-resolved merge, exactly as in Resolving Merge Conflicts Without Panic.
It is a one-line config change with no downside for solo or team use - each clone keeps its own recordings, and nothing is shared or pushed. Turn it on, and the second time a conflict shows up is the last time you solve it.
Share this post
Keep reading
Annotating Commits with git notes: Metadata Without Rewriting History
Some things belong on a commit but not in it: review links, benchmark results, the ticket nobody remembered to reference. git notes adds them after the fact, no rebase required.
Backing Up Your Git Server So It Actually Restores
Every clone is a partial backup - but hooks, config and server state live outside the repo. Mirror, bundle, copy off-site, and rehearse the restore.
Cherry-Picking: One Commit Without the Branch
Cherry-pick copies a single commit onto your branch and leaves the rest behind. Right for hotfixes across release branches, wrong as a sync strategy.