Finishing or Aborting a Merge

Learning Objectives

By the end of this lesson you will be able to:

Recognise that a merge is a state you are in, not just a command you ran
Abort a merge and return to exactly where you started
Finish a merge correctly and verify the result afterwards
Undo a merge that was already committed

Merging Is a State

When a merge conflicts, Git does not fail and walk away. It puts the repository into a merge state and waits for you. That state persists across terminal sessions, laptop reboots and lunch breaks.

You can always see it:

git status

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Two exits from this state: finish it, or abort it. There is no third door, and wandering off to do something else while still in it is how people get badly confused an hour later.

Aborting

git merge --abort

This returns the repository to exactly the state it was in before you ran git merge. Your branch pointer, your working directory, your index — all restored. Nothing is lost, including any uncommitted changes you had before starting.

Abort when:

The conflict is bigger than you expected and you want to prepare first
You realise you are on the wrong branch — very common, and completely recoverable
You need to ask someone a question before deciding, and would rather not leave the repository half-merged
You simply want to start again with a clear head

There is no cost and no stigma. Aborting an unpleasant merge, refreshing from main, and retrying is often faster than pushing through.

The one condition: --abort needs your pre-merge state to be recoverable. If you started the merge with uncommitted changes and then edited more files during resolution, Git may refuse rather than risk your work. The lesson is the one Module 2 already gave: start a merge from a clean working tree.

Finishing

Once every conflicted file is resolved and staged:

git status                # confirm: no unmerged paths
git commit                # conclude the merge

You can also be explicit:

git merge --continue

That is identical to git commit here — it exists so the same word works across merge, rebase and cherry-pick.

Verify Afterwards

The merge commit is created. You are not done.

git log --graph --oneline -5

Confirm the merge commit exists and has two parents.

git diff HEAD~1 --stat

See what the merge actually changed relative to your branch's previous tip.

Then — and this is the part that is actually about testing — run the suite. A merge can be resolved perfectly at the text level and still produce a broken product, because the two sides made changes that are individually correct and jointly incompatible. Nothing catches that except running the code.

Undoing a Merge You Already Committed

It happens. Two situations, two different answers.

Not pushed yet

git reset --hard HEAD~1

Moves your branch back one commit, discarding the merge entirely. --hard also discards working-directory changes, so be sure you have nothing else in flight.

Safer, if you'd rather keep your files:

git reset --merge HEAD~1

Already pushed

Do not use reset on a branch other people have pulled — you would rewrite shared history and hand everyone a mess. Use a revert instead:

git revert -m 1 <merge-commit-id>

The -m 1 says "keep the first parent's side" — that is, undo the changes that came in from the merged branch, keeping the branch you merged into. Revert creates a new commit that reverses the merge, leaving history intact.

Pro Tip: Reverting a merge has a well-known follow-on effect: because the merge commit still exists in history, Git considers that branch already merged. Re-merging it later brings in nothing. If the branch needs to land again, the usual answer is to revert the revert. Say what you're doing in the commit message — this confuses everybody at least once.

Key Takeaways

A conflicted merge puts the repository in a merge state that persists until you resolve it
git merge --abort restores everything exactly as it was — use it freely
Start merges from a clean working tree so --abort always works
git commit (or git merge --continue) concludes a resolved merge
Always run the test suite after a merge; correct text can still be a broken product
Undo an unpushed merge with git reset --hard HEAD~1; undo a pushed one with git revert -m 1