How do you back out of a conflicted Git merge, and what does git merge --abort restore?

## The state a conflicted merge leaves behind An unfinished merge is not an accident Git has to guess about — it is explicit state. `.git/MERGE_HEAD` holds the commit being merged in, `.git/MERGE_MSG` holds the pre-composed commit message, and the index carries the conflicted paths at stages 1, 2 and 3. `ORIG_HEAD` records where HEAD pointed before the operation started. Because all of this is written down, backing out is a supported operation rather than a rescue. ## git merge --abort The primary command is `git merge --abort`. It resets the index and the working tree to the pre-merge state and clears the merge state files, leaving the branch pointing where it always pointed. Conceptually it is `git reset --merge` performed against the recorded pre-merge state, and Git documents the two as equivalent while `MERGE_HEAD` is present. The important caveat is spelled out in Git's own documentation: if there were **uncommitted changes in the working tree when the merge started**, `--abort` may not be able to reconstruct them. Git refuses to begin a merge that would clobber local modifications to files it needs to touch, but modifications to other files can survive into the merge and are not guaranteed to come back. The operational rule that follows is simple and worth stating in an interview: begin merges from a clean tree, committing or stashing first, so that abort is always a total, lossless reversal. ## git merge --quit Sometimes you do not want the changes undone — you want Git to stop *considering this a merge*. `git merge --quit` clears `MERGE_HEAD` and the associated state but leaves the index and working tree untouched. That is the right tool when you have already produced a resolution you want to keep but intend to commit it differently, or when you want to inspect the half-resolved tree without Git insisting the merge must be completed. It is a sharper instrument than `--abort` and correspondingly easier to leave a confusing state behind, so use it deliberately. ## Restarting one file instead of everything Aborting the whole merge to fix one badly resolved file is heavy-handed. Because the three versions of every conflicted path are still in the index until you stage it, `git checkout -m <file>` (equivalently `git restore --merge <file>`) regenerates the conflict markers for that path from its stages, letting you redo just that resolution. This is the answer to "I mangled the hunks in one file and cannot get back to the original conflict" — provided you have not yet staged that file, which is what discards the stages. ## The rebase equivalents A conflicted rebase has the same shape with different commands: `git rebase --abort` returns the branch to its pre-rebase tip, and `git rebase --quit` stops the rebase while leaving HEAD where the replay reached. The mental model is identical — explicit recorded state, a full rollback, and a state-forgetting variant. ## After the fact If you have already committed a merge you regret, abort is no longer relevant; you are undoing a commit. `ORIG_HEAD` still points at the pre-merge tip, and the reflog records every position HEAD held, so the branch tip is recoverable. That distinction — abort applies to an *in-progress* operation, reflog-based recovery applies once a commit exists — is exactly what a senior answer should draw. ## Why this is a senior question Juniors often experience a conflicted merge as a state they are trapped in, and respond by deleting the clone and re-cloning. The senior answer is that the state is bounded, documented and reversible; that the only real hazard is uncommitted work that predated the merge; and that there is a graduated set of responses — redo one file, forget the merge state, or roll the whole thing back — rather than a single panic button.