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 and the associate tree object; it repeats
this process until it gets all the necessary objects. Because
of this behavior, they are sometimes also called commit
walkers.
The commit walkers are sometimes also called dumb transports,
because they do not require any Git aware smart server like
Git Native transport does. Any stock HTTP server that does
not even support directory index would suffice. But you must
prepare your repository with git update-server-info to help
dumb transport downloaders.
Once you fetch from the remote repository, you merge that with
your current branch.
However — it's such a common thing to fetch and then immediately
merge, that it's called git pull, and you can simply do
$ git pull <remote-repository>
and optionally give a branch-name for the remote end as a second
argument.
Note
You could do without using any branches at all, by keeping as
many local repositories as you would like to have branches,
and merging between them with git pull, just like you merge
between branches. The advantage of this approach is that it
lets you keep a set of files for each branch checked out and
you may find it easier to switch back and forth if you juggle
multiple lines of development simultaneously. Of course, you
will pay the price of more disk usage to hold multiple
working trees, but disk space is cheap these days.
It is likely that you will be pulling from the same remote
repository from time to time. As a short hand, you can store the
remote repository URL in the local repository's config file like
this:
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
and use the "linus" keyword with git pull instead of the full
URL.
Examples.
1. git pull linus
2. git pull linus tag v0.99.1
the above are equivalent to:
1. git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD
2. git pull http://www.kernel.org/pub/scm/git/git.git/ tag
v0.99.1
