Git rerere records conflict resolutions so a similar conflict can be resolved again with less manual work. The name refers to reusing recorded resolution. It can save time during repeated merges, rebases, and integration testing, but a previously accepted textual fix is not proof that the new result is semantically correct.
The safest workflow treats a reused resolution as a proposed change that still needs inspection and testing. This guide explains recording, index behavior, review, and recovery so convenience does not silently replace the team’s normal correctness checks.
Start with the conflict workflow you actually use
Identify why conflicts repeat. A long-running topic branch, repeated integration rehearsal, or rebasing through related changes may benefit from recorded resolutions. Rerere is less useful when each conflict is structurally unrelated.
Enable the feature through the supported Git configuration for the intended scope. Choose repository-local configuration if only one project should use it. A global setting changes behavior across other repositories too.
Document the setting for collaborators, but do not assume their local configuration matches yours. The same merge can appear differently depending on recorded history and autoupdate behavior. Shared review should focus on the resulting change.
Understand what the recorded resolution represents
Rerere associates a conflicted merge result with a later manual resolution according to Git’s matching behavior. It reuses that information when a suitable conflict appears. It does not infer the product requirement or current architecture.
A textual pattern can recur while surrounding code or assumptions change. A resolution that once selected one side may now discard a necessary validation or interface update. Treat reused content as something to verify in context.
Keep the first manual resolution careful. If the original fix was wrong, repeated reuse can make the error efficient rather than correct. Run relevant tests and review the first resolution before relying on its future value.
Separate working-tree changes from staged acceptance
Autoupdate settings affect whether reused resolutions update the index in addition to the working tree. This distinction matters because a staged result can be easier to commit without noticing what the tool chose.
For a review-first workflow, inspect the documented no-autoupdate option where supported by the operation. Then review the working-tree result before explicitly staging it. Confirm the actual behavior in your Git version.
Regardless of configuration, use git status and appropriate diffs to inspect both unstaged and staged state. A clean conflict marker count is not equivalent to an approved resolution. The index is a publication boundary worth checking deliberately.
Inspect the complete resulting change
Read the resolved section together with relevant surrounding code. Check names, imports, data flow, and error paths. A resolution can compile while silently selecting an outdated assumption.
Review changes outside the original conflict as well. The merge or rebase may bring other modifications that interact with the reused result. Correctness belongs to the combined branch, not only the three lines that previously conflicted.
Keep generated files under their normal workflow. A reused resolution in a lockfile or generated artifact may need regeneration from approved inputs. Do not assume matching text establishes a valid dependency contract.
Test semantic behavior, not only syntax
Run tests that cover the conflicting feature and its important boundaries. Syntax checks are useful but cannot prove that an authorization rule, retry decision, or schema migration kept its intended meaning.
Add a regression test when a conflict exposes a fragile assumption. Repeated manual and reused resolutions then have a clearer acceptance criterion. The test should represent required behavior rather than encode whichever side happened to win.
For security-sensitive changes, review failure behavior as well as successful requests. A merge that retains the happy path while dropping a denial case can pass a shallow demonstration and still weaken the application.
Recognize and recover from a wrong reuse
If a reused resolution is wrong, stop before committing it. Preserve any work you need, inspect the current operation, and use the supported rerere forgetting or clearing behavior appropriate to the situation.
Do not indiscriminately delete repository internals as a first response. Git provides commands for inspecting and managing recorded resolutions. Consult their behavior so the recovery does not discard unrelated useful records unexpectedly.
Resolve the conflict correctly and verify the final state again. If the wrong result was already published, use the team’s normal corrective-change process. Local resolution-cache cleanup does not repair a committed branch on the remote.
Keep history operations and ownership deliberate
Rerere helps with conflict work; it does not choose whether merge or rebase is appropriate for shared history. Follow the branch policy and coordinate before rewriting commits others may already depend on.
Do not make force-pushing seem safer simply because conflicts resolved automatically. Publication of rewritten history has its own collaboration risks. Verify the remote state and the allowed update method separately.
Retain a recovery point when performing a complex integration. Recorded resolutions are not a substitute for knowing the original branch state. A clear starting commit makes comparison and abandonment of a failed attempt easier.
Build a repeatable review routine
Before integration, record the starting references and run the baseline tests. During conflicts, inspect what rerere reused, review complete diffs, and verify the index. After integration, run the full relevant acceptance checks.
Keep diagnostic records concise and nonsecret. A conflict may contain private source, credentials mistakenly committed in history, or customer-specific fixtures. Do not paste all recorded content into broad issue trackers.
For a feature branch repeatedly tested against a moving main branch, rerere can reduce repeated editing while tests and review preserve correctness. The productivity gain comes from reusable mechanical work, not from exempting the branch from evaluation.
Frequently asked questions
Does a reused resolution guarantee correctness?
No. It reuses a recorded textual resolution that still needs contextual review and testing.
Can rerere automatically stage a result?
Configuration and operation options can affect index updates. Check autoupdate behavior before relying on it.
Where should I verify management commands?
Read the Git rerere reference for inspection, forgetting, clearing, and supported options.
For a complementary workflow, read Git Rebase vs Merge: 7 Checks for a Safer Team Workflow.
