Q: `git rerere` is enabled in your config. What does it do, and in what workflows does it save the most time?

rerere stands for "reuse recorded resolution." When enabled (git config --global rerere.enabled true), Git silently records how you resolved each merge conflict. If the *exact same* conflict appears again later, Git applies the same resolution automatically.

• You hit a conflict during merge or rebase and manually resolve it.
• Git records the conflict (before) and resolution (after) in .git/rr-cache/.
• Next time the same conflict appears (same pre-image), Git auto-applies your recorded resolution. You still need to git add and commit, but the file is already correctly resolved.
• Long-lived feature branches that you repeatedly rebase onto main. Each rebase replays all commits, and the same conflicts keep appearing. With rerere, you resolve each conflict once; subsequent rebases are automatic.
• Topic branch workflows where you test-merge branches into an integration branch, then discard the merge and re-merge later for the real release. Without rerere, you re-resolve every conflict.

How it works: Where it shines: Caveats:

• Cherry-pick-heavy workflows (backporting fixes across release branches) where similar conflicts recur.
• The cache is local — not shared across clones. Each developer's rerere database is separate.
• If you resolve a conflict incorrectly, rerere will faithfully re-apply the wrong resolution. Use git rerere forget to clear a bad recording.
• git rerere gc cleans up old recordings (default: unresolved conflicts older than 15 days, resolved ones older than 60 days).