is cleanly resolved or unmodified.
------------

while in `zdiff3` style, it may look like this:

------------
Here are lines that are either unchanged from the common
ancestor, or cleanly resolved because only one side changed,
or cleanly resolved because both sides changed the same way.
<<<<<<< yours:sample.txt
Conflict resolution is hard;
let's go shopping.
||||||| base:sample.txt
or cleanly resolved because both sides changed identically.
Conflict resolution is hard.
=======
Git makes conflict resolution easy.
>>>>>>> theirs:sample.txt
And here is another line that is cleanly resolved or unmodified.
------------

In addition to the +<<<<<<<+, `=======`, and +>>>>>>>+ markers, it uses
another +|||||||+ marker that is followed by the original text.  You can
tell that the original just stated a fact, and your side simply gave in to
that statement and gave up, while the other side tried to have a more
positive attitude.  You can sometimes come up with a better resolution by
viewing the original.


HOW TO RESOLVE CONFLICTS
------------------------

After seeing a conflict, you can do two things:

 * Decide not to merge.  The only clean-ups you need are to reset
   the index file to the `HEAD` commit to reverse 2. and to clean
   up working tree changes made by 2. and 3.; `git merge --abort`
   can be used for this.

 * Resolve the conflicts.  Git will mark the conflicts in
   the working tree.  Edit the files into shape and
   `git add` them to the index.  Use `git commit` or
   `git merge --continue` to seal the deal. The latter command
   checks whether there is a (interrupted) merge in progress
   before calling `git commit`.

You can work through the conflict with a number of tools:

 * Use a mergetool.  `git mergetool` to launch a graphical
   mergetool which will work through the merge with you.

 * Look at the diffs.  `git diff` will show a three-way diff,
   highlighting changes from both the `HEAD` and `MERGE_HEAD`
   versions. `git diff AUTO_MERGE` will show what changes you've