Skip to content

Git Rerere: Reuse Recorded Resolution

git rerere (Reuse Recorded Resolution) is an automated conflict resolution memory engine built into Git. It records how you resolved a conflicted chunk (pre-image, post-image) and automatically applies that exact resolution whenever the same conflict signature reappears in future merges, rebases, or cherry-picks.


Why a DevOps & Release Engineer Needs Rerere

  1. Long-Running Feature Branches & Rebase Fatigue
  2. Developers rebasing long-lived feature branches against a rapidly advancing main often face the exact same merge conflicts day after day. Rerere remembers the manual resolution from Day 1 and auto-resolves it on Days 2–30.
  3. Ephemeral Integration / Staging Merges (Throwaway Test Branches)
  4. In CI/CD pipelines, release engineers frequently merge several active feature branches into a temporary staging or integration branch to run test suites without polluting feature branch history with merge commits.
  5. When the throwaway branch is deleted and rebuilt tomorrow, Rerere remembers previous conflict resolutions so the CI merge step succeeds unattended.
  6. Multi-Branch Backport & Cherry-Pick Trains
  7. Backporting bugfixes across multiple maintenance/LTS branches (release/v1.2, release/v1.3, release/v2.0) frequently triggers identical conflict blocks. Rerere handles the repetitive fixes instantly.
  8. Git Bisect Across Conflicted History
  9. When running automated git bisect across branches requiring test merges, Rerere applies recorded resolutions silently without blocking CI scripts.

How It Works Under the Hood

When a conflict occurs: 1. Git calculates a SHA-1 fingerprint of the conflict hunk (the pre-image) and creates a directory in .git/rr-cache/<hash>/. 2. The initial conflict marker contents are saved as preimage. 3. When you resolve the conflict and stage or commit the file (git add), Git inspects the resolved state and records it as postimage. 4. The next time Git encounters the same preimage conflict, it automatically patches the file with postimage and notifies you: Resolved 'file.txt' using previous resolution.


Enabling & Configuring Rerere

Rerere is disabled by default in standard Git installations. Enable it globally or per-repository:

# Enable recording of merge resolutions
git config --global rerere.enabled true

# Optional: automatically stage auto-resolved files into git index
git config --global rerere.autoupdate true

# Recommended: enhanced 3-way diff markers for clear conflict context
git config --global merge.conflictstyle zdiff3

Note on rerere.autoupdate: - Without rerere.autoupdate: Git resolves the conflict in the working tree, but leaves the file unstaged so you can inspect it with git diff before running git add. - With rerere.autoupdate: Git resolves and stages (git add) the file immediately if the conflict was fully resolved.


Common DevOps Workflows & Scenarios

Scenario 1: Ephemeral Test Merges in CI/CD

# Release engineer creates an ephemeral integration branch
git checkout -b integration/nightly origin/main

# Merge feature A (conflicts occur and are resolved manually once)
git merge origin/feature-auth
# Fix conflicts in config/auth.yaml
git add config/auth.yaml
git commit -m "chore: resolve auth merge conflict"

# CI runs tests on integration/nightly...
# Next day, delete the throwaway branch:
git branch -D integration/nightly

# Re-create fresh integration branch the next night:
git checkout -b integration/nightly origin/main
git merge origin/feature-auth
# Output: "Resolved 'config/auth.yaml' using previous resolution."
# No human intervention required!

Scenario 2: Rebasing Feature Branches Without Repeated Pain

git checkout feature/observability
git rebase origin/main
# First conflict encountered -> fix file, stage, continue
git add src/telemetry/metrics.go
git rebase --continue
# Rerere records the resolution.

# Later, new commits land on origin/main, developer rebases again:
git fetch origin
git rebase origin/main
# Git applies recorded resolution automatically!

Troubleshooting & Managing Rerere Cache

1. Check Rerere Status

# Show which files currently have active recorded resolutions
git rerere status

# View the diff between pre-image conflict and current resolution
git rerere diff

2. Forgetting a Bad Resolution

If you resolved a conflict incorrectly and staged it, Rerere recorded the bad resolution. Reset it:

# Forget the recorded resolution for a specific file
git rerere forget path/to/conflicted-file.py

# Re-open the conflict markers to resolve properly:
git checkout --conflict=merge path/to/conflicted-file.py
# (Or with zdiff3: git checkout --conflict=zdiff3 path/to/conflicted-file.py)

3. Cache Maintenance & Garbage Collection

Git automatically prunes old resolutions, but you can manage it explicitly:

# Prune unresolved conflict records older than 15 days
# and resolved records older than 60 days
git rerere gc

# Clear all uncommitted conflict state
git rerere clear

Advanced: Sharing Rerere Cache Across CI Runners or Teams

The Rerere database lives in .git/rr-cache/. You can synchronize this directory across CI nodes or team members:

# Option A: Archive and cache in CI pipeline artifact store (e.g. S3 / GCS / CI Cache)
tar -czf rr-cache.tar.gz -C .git rr-cache

# Option B: Restore on another CI runner
mkdir -p .git/rr-cache
tar -xzf rr-cache.tar.gz -C .git/