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.

------------
$ git switch mybranch
$ git merge -m "Merge upstream changes." master
------------

This outputs something like this (the actual commit object names
would be different)

----------------
Updating from ae3a2da... to a80b4aa....
Fast-forward (no commit created; -m option ignored)
 example | 1 +
 hello   | 1 +
 2 files changed, 2 insertions(+)
----------------

Because your branch did not contain anything more than what had
already been merged into the `master` branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the `master` branch. This is
often called 'fast-forward' merge.

You can run `gitk --all` again to see how the commit ancestry
looks like, or run 'show-branch', which tells you this.

------------------------------------------------
$ git show-branch master mybranch
! [master] Merge work in mybranch
 * [mybranch] Merge work in mybranch
--
-- [master] Merge work in mybranch
------------------------------------------------


Merging external work
---------------------

It's usually much more common that you merge with somebody else than
merging with your own branches, so it's worth pointing out that Git
makes that very easy too, and in fact, it's not that different from
doing a 'git merge'. In fact, a remote merge ends up being nothing
more than "fetch the work from a remote repository into a temporary tag"
followed by a 'git merge'.

Fetching from a remote repository is done by, unsurprisingly,
'git fetch':

----------------
$ git fetch <remote-repository>
----------------

One of the following transports can be used to name the
repository to download from:

SSH::
	`remote.machine:/path/to/repo.git/` or
+
`ssh://remote.machine/path/to/repo.git/`
+
This transport can be used for both uploading and downloading,
and requires you to have a log-in privilege over `ssh` to the
remote machine.  It finds out the set of objects the other side
lacks by exchanging the head commits both ends have and
transfers (close to) minimum set of objects.  It is by far the
most efficient way to exchange Git objects between repositories.

Local directory::
	`/path/to/repo.git/`
+
This transport is the same as SSH transport but uses 'sh' to run
both ends on the local machine instead of running other end on
the remote machine via 'ssh'.

Git Native::
	`git://remote.machine/path/to/repo.git/`
+
This transport was designed for anonymous downloading.  Like SSH
transport, it finds out the set of objects the downstream side
lacks and transfers (close to) minimum set of objects.

HTTP(S)::
	`http://remote.machine/path/to/repo.git/`
+
Downloader from http and https URL
first obtains the topmost commit object name from the remote site
by looking at the specified refname under `repo.git/refs/` directory,
and then tries to obtain the
commit object by downloading from `repo.git/objects/xx/xxx...`
using the object name of that commit object.  Then it reads the
commit object to find out its parent commits