This article will describe how to incrementally resolve the conflicts
in a merge diagram, one pairwise conflict at a time. Each time a
conflict is manually resolved, the conflict frontier is pushed back
and more of the merge diagram becomes green. When the whole conflict
diagram is green, the full incremental merge is done.

The amazing thing is that an incremental merge, once completed,
contains all of the information you could possibly want about
combining two branches. In my next article I will show, given a
full incremental merge, how to derive a simple merge, a rebase (in
either direction), or a rebase-with-history.

Remember: in this diagram, commits "0"-"11" are on master and commits
"A"-"I" are on the branch. The rest of the diagram shows incremental
merges when they are possible; e.g., commit "C3" is a successful merge
between commit "C2" and commit "B3". When a pairwise merge fails, the
diagram shows an "x"; for example Git was unable to merge "E2" and
"F1", which implies that there was some conflict between the changes
introduced in master commit "2" and those introduced in branch commit
"F".

But you are smarter than Git, so (hopefully) you can merge "E2" and
"F1" manually. Among your advantages over Git is that you can
understand the commit messages for commits "2" and "F", so you know
what those two commits were trying to achieve. Your task is to create
a commit "F2" that contains the changes made in both "2" and "F"
[1]. Once you resolve those two changes and commit the results as
"F2", the diagram is transformed to:

Not only has "F2" been added to the diagram, but also a white area has
opened up below and to the right of "F2". These merges used to be
blocked by the conflict at "F2". But since we have merged "F2"
manually, it might be that Git can now do some or all of these merges
automatically. For example, we can now attempt to merge "E3" and "F2"
to create "F3", or merge "F2" and "G1" to create "G2", and continue
filling in the white area until we are blocked by new conflicts.

If we are lucky, the conflict "F2" was isolated and the whole block is
now mergeable:

Of course we might not be so lucky, and new conflicts might be
revealed in the rectangle previously blocked by "F2". But either way,
we have made at least some progress in pushing back the conflict
frontier.

If we continue merging commits pairwise--automatically when possible,
manually when necessary--eventually we will clear the whole diagram of
conflicts. When this is accomplished, the incremental merge is done:

But when the incremental merge is done, the full merge is also done!
Commit "I11" combines all of the changes from "master" with all of the
changes from "branch"; in other words, it is the merge of "master" and
"branch". The merge nightmare is over.

Notes:

The technical reason why merging "E2" and "F1" into "F2" is
simpler than merging "2" and "F" directly is that "E2" and "F1"
share nearby commit "E1" as a merge base (see the documentation
for git-merge-base(1)). By contrast, the merge base of "2"
and "F" is commit "0", which is further away from the commits
to be merged.