merge is all about:

------------
$ git merge -m "Merge work in mybranch" mybranch
------------

where the first argument is going to be used as the commit message if
the merge can be resolved automatically.

Now, in this case we've intentionally created a situation where the
merge will need to be fixed up by hand, though, so Git will do as much
of it as it can automatically (which in this case is just merge the `example`
file, which had no differences in the `mybranch` branch), and say:

----------------
	Auto-merging hello
	CONFLICT (content): Merge conflict in hello
	Automatic merge failed; fix conflicts and then commit the result.
----------------

It tells you that it did an "Automatic merge", which
failed due to conflicts in `hello`.

Not to worry. It left the (trivial) conflict in `hello` in the same form you
should already be well used to if you've ever used CVS, so let's just
open `hello` in our editor (whatever that may be), and fix it up somehow.
I'd suggest just making it so that `hello` contains all four lines:

------------
Hello World
It's a new day for git
Play, play, play
Work, work, work
------------

and once you're happy with your manual merge, just do a

------------
$ git commit -i hello
------------

which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
message about your adventures in 'git merge'-land.

After you're done, start up `gitk --all` to see graphically what the
history looks like. Notice that `mybranch` still exists, and you can
switch to it, and continue to work with it if you want to. The
`mybranch` branch will not contain the merge, but next time you merge it
from the `master` branch, Git will know how you merged it, so you'll not
have to do _that_ merge again.

Another useful tool, especially if you do not always work in X-Window
environment, is `git show-branch`.

------------------------------------------------
$ git show-branch --topo-order --more=1 master mybranch
* [master] Merge work in mybranch
 ! [mybranch] Some work.
--
-  [master] Merge work in mybranch
*+ [mybranch] Some work.
*  [master^] Some fun.
------------------------------------------------

The first two lines indicate that it is showing the two branches
with the titles of their top-of-the-tree commits, you are currently on
`master` branch (notice the asterisk `*` character), and the first
column for the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. Three commits are shown along with their titles.
All of them have non blank characters in the first column (`*`
shows an ordinary commit on the current branch, `-` is a merge commit), which
means they are now part of the `master` branch. Only the "Some
work" commit has the plus `+` character in the second column,
because `mybranch` has not been merged to incorporate these
commits from the master branch.  The string inside brackets
before the commit log message is a short name you can use to
name the commit.  In the above example, 'master' and 'mybranch'
are branch heads.  'master^' is the first parent of 'master'
branch head.  Please see linkgit:gitrevisions[7] if you want to
see more complex cases.

[NOTE]
Without the '--more=1' option, 'git show-branch' would not output the
'[master^]' commit, as '[mybranch]' commit is a common ancestor of
both 'master' and 'mybranch' tips.  Please see linkgit:git-show-branch[1]
for details.

[NOTE]
If there were more commits on the 'master' branch after the merge, the
merge commit itself would not be shown by 'git show-branch' by
default.  You would need to provide `--sparse` option to make the
merge commit visible in this case.

Now, let's pretend you are the one who did all the work in
`mybranch`, and the fruit of your hard work has finally been merged
to the `master` branch. Let's go back to `mybranch`, and run
'git merge' to get the "upstream changes" back to your branch.

------------