When a merge conflicts

A conflict is Git saying that two sides changed the same part of the same file and it will not guess which one you meant. The operation — merge, rebase, pull, cherry-pick, revert — stops, and waits.

Nothing is lost while it is stopped. Both versions are still there, the operation can be abandoned, and the repository goes back to where it was.

Finding the files

Conflicted files get their own state in the working copy and their own mark, so the list tells you how many there are and which. Innesta puts shortcuts to them wherever you might be when a conflict happens, because the annoying part of resolving several is finding the next one.

Resolving

Open a conflicted file and you get the three-pane editor. For each hunk, take one side, take the other, or write the answer yourself.

Some hunks do not need a decision at all — both sides made the same change, or only one side changed anything. Resolve Simple Conflicts settles those in one action and leaves everything ambiguous alone.

Finishing

Finishing a file with Mark Resolved stages it in the same step. When every conflicted file is resolved, Continue in the status bar completes the operation that stopped.

• After a merge, Continue makes the merge commit, using the signing toggle as it stands.
• After a rebase, Continue moves on to the next commit — which may conflict in turn, because a rebase applies your commits one at a time.

Giving up

An operation in progress can be abandoned, and the repository returns to its state before it started. That is worth remembering when a merge turns out to be a bigger job than you have time for: stopping is free.