Git Rerere: Automating Your Git Merge Conflict Resolution
Master git rerere to automate git merge conflict resolution. Stop fixing the same bugs twice and optimize your git workflow with this hidden feature.
I remember sitting through an hour-long rebase session during a massive refactor, fixing the exact same conflict in user_controller.rb four separate times. It was a tedious, brain-numbing exercise that left me wondering why I wasn't using the tools available to me. If you’ve ever felt like your git workflow optimization is just a series of repetitive manual fixes, it’s time to look at git rerere.
git rerere stands for "reuse recorded resolution." It’s a built-in feature that keeps track of how you resolved a merge conflict and automatically applies that same fix the next time it sees a similar scenario.
Enabling Git Rerere
The feature isn't on by default in most Git installations. To start using it, you need to enable it in your local configuration. I usually set it globally, but you can also enable it per-repository if you’re working on a sensitive project.
Run this command in your terminal:
Bashgit config --global rerere.enabled true
Once enabled, Git begins recording conflict resolutions. You don't need to do anything else. When you encounter a conflict, resolve it as you normally would, stage the files, and commit. Git stores the "before" (the conflicting state) and the "after" (your resolution) in .git/rr-cache.
How It Works in Practice
Let’s say you’re working on a feature branch and you need to keep it up to date with main. If you’ve resolved a conflict in a specific file before, Git will notice the pattern the next time you perform a merge or rebase.
When a conflict occurs that matches a recorded resolution, Git will print:
Recorded resolution for 'path/to/file'
It automatically updates the file with your previous fix. You still need to git add the resolved file, but you skip the manual editing process entirely. This is a massive time-saver, especially when you have long-running branches that require frequent syncs with the upstream.
When to Use It (and When to Be Careful)
I’ve found git rerere to be a godsend for complex refactors, but it isn't a silver bullet. You should consider the following trade-offs:
| Feature | Benefit | Risk |
|---|---|---|
| Automation | Saves minutes of manual conflict resolution. | Might hide logical errors if your fix wasn't actually correct. |
| Consistency | Ensures the same resolution is applied every time. | Can propagate bad code patterns if you aren't careful. |
| Visibility | Keeps your Git history clean of "fix merge" commits. | Harder to audit why a conflict was resolved a certain way later. |
If you are dealing with LLM agents conflict resolution: merging divergent workflow outputs, rerere can be incredibly useful to maintain consistency across automated merges. However, if the underlying code is changing rapidly, an automated resolution might mask a subtle bug introduced by a new dependency or a logic shift.
Before relying on this for critical production code, ensure your CI/CD philosophy: automating your software delivery includes robust test suites. If your automated merge passes the tests, you're likely in the clear.
Common Pitfalls
I once spent about two hours debugging a "weird" code behavior only to realize rerere had applied a resolution from three weeks ago that was no longer valid due to a refactor in a different module.
- Audit your cache: If things seem off, you can clear the cache using
git rerere forget <path>. - Don't ignore the merge: Even with
rerere, always run your test suite after a merge. Automation is great, but it doesn't replace verification. - Context matters:
rerereis best for repetitive conflicts caused by re-syncing branches, not for complex architectural merges where every conflict needs fresh eyes.
FAQ
Q: Does git rerere work across different machines?
A: No. The rr-cache lives inside your local .git directory. It won't be pushed to your remote repository, so your teammates won't inherit your recorded resolutions.
Q: Can I see what git rerere has recorded?
A: Yes. You can look into the .git/rr-cache directory, though the files are stored in a format that isn't particularly human-readable. It’s mostly for Git’s internal use.
Q: Is it safe to leave enabled permanently?
A: In my experience, yes. I’ve had rerere.enabled set to true on my machine for over two years. The only time it causes trouble is when I forget that I’ve automated a fix that I should have manually reviewed.
git rerere isn't a magic button, but it’s a standard part of my toolkit for keeping my local environment sane. If you're tired of playing "fix the same merge conflict" every morning, turn it on and see how it changes your workflow. Just don't let the automation make you lazy—always verify your merges.