git rerere: Usage, Options & Common CI Errors
git rerere remembers how you resolved a conflict and reapplies it next time the same conflict appears.
On long-running branches that rebase repeatedly, rerere ("reuse recorded resolution") saves you from solving the same conflict over and over by replaying your earlier fix.
What it does
When enabled, git rerere records the pre-image and your resolution of each conflict. The next time an identical conflict occurs, it auto-applies the stored resolution and stages the result.
Common usage
git config --global rerere.enabled true
git rerere status # conflicts being recorded
git rerere diff # what the recorded resolution changes
git rerere forget <path> # discard a bad recorded resolutionOptions
| Subcommand | What it does |
|---|---|
| (config) rerere.enabled | Turn the feature on |
| status | Show conflicts currently tracked |
| diff | Show the recorded resolution diff |
| forget <path> | Drop a recorded resolution |
| gc / clear | Prune the recorded-resolution cache |
Common errors in CI
rerere state lives under .git/rr-cache, which is local and not cloned - fresh CI checkouts have no recorded resolutions, so it helps persistent workspaces, not ephemeral runners. A wrong auto-resolution is silent; if rerere reapplies a bad fix, run git rerere forget <path> and re-resolve.
Using this in CI
CI checkouts are shallow and detached by default, which changes the answer this command gives you. Commands that read history, branch names, or tags need the checkout configured for it.
- uses: actions/checkout@v4
with:
fetch-depth: 0 # history, tags, and git describe all need this
- run: |
git rev-parse --is-shallow-repository # expect false
git rev-parse --abbrev-ref HEAD # prints HEAD when detached