Git Merge Continue and Abort: Completing or Abandoning an In-Progress Merge

Intermediate

Resolution and completion are different states

V439 left us with a merge still in progress, but with its conflicts resolved and staged. That is not yet a merge commit. The repository still has merge-state information such as MERGE_HEAD, while HEAD still names the receiving branch's pre-merge commit. V440 owns the final transition: continue the resolved merge to create the merge commit, or abort an in-progress conflicted merge to return to the pre-merge state.

git status --short
git rev-parse HEAD
git rev-parse MERGE_HEAD
git ls-files --unmerged

All conflict paths have been staged and `git ls-files --unmerged` is empty.?MERGE_HEAD still identifies the commit being merged and HEAD still identifies the receiving branch's pre-merge commit.

Continue a resolved merge

Once every conflicted path is resolved and staged, `git merge --continue` concludes the interrupted merge. Git checks that an interrupted merge is in progress and then creates the merge commit from the prepared index and merge state. The receiving branch advances to the new merge commit; the incoming commit remains an ancestor through the new commit's second parent. The command is therefore a history transition, not another conflict-resolution command.

git ls-files --unmerged
git add conflict.txt
GIT_EDITOR=true git merge --continue
git status --short --branch
git log --oneline --decorate -3

The merge is in progress and every conflict path has been staged.?HEAD points to a new merge commit and the merge-in-progress state is cleared.

The merge commit records both histories

A completed true merge records the receiving branch's previous tip and the merged branch's tip as parents of the new merge commit. This is different from a fast-forward, where no new merge commit is needed. V437 established that history shape; here the important boundary is that `git merge --continue` creates that commit only after the interrupted merge has been resolved.

git rev-list --parents -n 1 HEAD
git rev-parse HEAD^1
git rev-parse HEAD^2

A true merge has been completed.?HEAD^1 identifies the receiving branch's previous tip and HEAD^2 identifies the merged branch's tip.

Abort abandons the in-progress merge

If you decide not to merge, `git merge --abort` abandons the current conflict-resolution process and attempts to reconstruct the pre-merge state. In a clean disposable laboratory, this means the receiving branch returns to its pre-merge tip, the merge-in-progress state is cleared, and the conflict markers or staged merge result disappear. The official documentation warns that non-trivial uncommitted changes present when the merge starts can make exact reconstruction impossible, so this curriculum uses clean repositories for deterministic recovery demonstrations.

git merge feature
# conflict occurs
git merge --abort
git status --short --branch
git rev-parse HEAD
git rev-parse --verify MERGE_HEAD

A merge has stopped with conflicts.?The repository is reconstructed toward its pre-merge state and the merge operation is no longer in progress.

Continue and abort are mutually exclusive endings

Think of an interrupted merge as a state machine. After the merge stops, you inspect and resolve paths (V438–V439). From the resolved state, `git merge --continue` commits the prepared result. From the in-progress state, `git merge --abort` abandons the operation and returns toward the pre-merge state. Neither command is a substitute for editing and staging unresolved paths, and neither should be presented as a generic undo command.

A merge has stopped because of conflicts.?All conflicts are resolved and staged, then the interrupted merge is completed and verified as a merge commit.

Practice what you learned

Use the dedicated Git code-completion exercise for this lesson.