Every few weeks I hit the same merge conflict. Same file, same lines, same decisions. For years I just dealt with it — resolve, commit, move on. Then I stumbled over rerere and now I dont go back.
What it does
rerere stands for "Reuse Recorded Resolution." Git remembers how you resolved a conflict and auto-applies that resolution the next time it sees the same conflict. You resolve it once, and future merges handle it without you.
Setup
One command:
git config --global rerere.enabled true
That creates the directory, enables the behavior globally. Youre done.
How it works
When you hit a conflict, git records what the conflict looks like and what you chose. On a future merge with the same conflict, git auto-resolves it and tells you: Resolved using previous resolution. You just git add . and git merge --continue.
Its not magic — it only works when the conflict hunk is byte-for-byte identical to a previous one. But when you have recurring branch conflicts (release branches, long-lived feature branches that rebase onto main), it hits often enough to matter.
When it helps
The pattern I see it help most: teams with a main branch that multiple feature branches merge into repeatedly. Each integration hits the same few files. Instead of resolving the same user.rb conflict for the fourth time, you resolve it once and git handles the rest.
Its also useful for rebasing — same idea, just replayed through a different context.
When it doesnt
If the conflict text changes (different surrounding context, refactored file), rerere wont match it. Its not a substitute for understanding what youre merging.
Worth knowing
The resolutions are stored in .git/rr-cache. If youre working on something sensitive, remember this is local but persistent. Not an issue for most workflows, just worth noting.
I enabled it about a year ago and have had maybe three or four situations where it kicked in. Each time it shaved off a few minutes of tedious work. Thats enough to keep it on.
Top comments (0)