Conflicts resulting from anything except merges

Git can also encounter a conflict when it tries to apply a patch. Commands that apply patches include rebase, revert, cherry-pick, and am.

In this case, the resulting history will look like this:

(N)     - new revision - the position of the current branch when the command finishes
 |
(L)     - left side (ORIG_HEAD) - the revision to which the patch is being applied

    (R) - right side - the "new" revision from when the patch was created
     |
    (O) - old revision - the "old" revision from when the patch was created

In this case, "R" and "O", the revisions used to create the patch, have no particular relationship to "L" or "N", the revisions you're working on now. They don't even have to be commits; the git am command can apply patches from someone else's tree.

Git will mark the conflicting files with

<<<<<<<

=======

and

>>>>>>>

tags the same way it does with merges.

Three-way diffs will be generated the same way.

The only important difference is in the meaning of "left side" and "right side".

"Left side" means the revision to which the patch is being applied.

"Right side" means the "new" revision used in creating the patch, the one marked with pluses.

When rebasing, this can mean the sides are the reverse of what you might expect. Just remember how rebasing works: It moves your current branch to where the other branch is and then applies patches on top of it. Because the changes that were in your current branch are applied as patches, they end up on the right side.

I should also note that, in a revert, the diagram looks like this:

(N)     - new revision - the position of the current branch when the command finishes
 |
(L)     - left side (ORIG_HEAD) - the revision to which the patch is being applied

    (O) - old revision - the commit being reverted
     |
    (R) - right side - the commit just before the one being reverted