Git branching: master vs. origin/master vs. remotes/origin/master
Technically there aren't actually any "remote" things at all1 in your Git repo, there are just local names that should correspond to the names on another, different repo. The ones named origin/whatever
will initially match up with those on the repo you cloned-from:
git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...
makes a local copy of the other repo. Along the way it notes all the branches that were there, and the commits those refer-to, and sticks those into your local repo under the names refs/remotes/origin/
.
Depending on how long you go before you git fetch
or equivalent to update "my copy of what's some.where.out.there", they may change their branches around, create new ones, and delete some. When you do your git fetch
(or git pull
which is really fetch plus merge), your repo will make copies of their new work and change all the refs/remotes/origin/<name>
entries as needed. It's that moment of fetch
ing that makes everything match up (well, that, and the initial clone, and some cases of push
ing too—basically whenever Git gets a chance to check—but see caveat below).
Git normally has you refer to your own refs/heads/<name>
as just <name>
, and the remote ones as origin/<name>
, and it all just works because it's obvious which one is which. It's sometimes possible to create your own branch names that make it not obvious, but don't worry about that until it happens. :-) Just give Git the shortest name that makes it obvious, and it will go from there: origin/master
is "where master was over there last time I checked", and master
is "where master is over here based on what I have been doing". Run git fetch
to update Git on "where master is over there" as needed.
Caveat: in versions of Git older than 1.8.4, git fetch
has some modes that don't update "where master is over there" (more precisely, modes that don't update any remote-tracking branches). Running git fetch origin
, or git fetch --all
, or even just git fetch
, does update. Running git fetch origin master
doesn't. Unfortunately, this "doesn't update" mode is triggered by ordinary git pull
. (This is mainly just a minor annoyance and is fixed in Git 1.8.4 and later.)
1Well, there is one thing that is called a "remote". But that's also local! The name origin
is the thing Git calls "a remote". It's basically just a short name for the URL you used when you did the clone. It's also where the origin
in origin/master
comes from. The name origin/master
is called a remote-tracking branch, which sometimes gets shortened to "remote branch", especially in older or more informal documentation.
Take a clone of a remote repository and run git branch -a
(to show all the branches git knows about). It will probably look something like this:
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Here, master
is a branch in the local repository. remotes/origin/master
is a branch named master
on the remote named origin
. You can refer to this as either origin/master
, as in:
git diff origin/master..master
You can also refer to it as remotes/origin/master
:
git diff remotes/origin/master..master
These are just two different ways of referring to the same thing (incidentally, both of these commands mean "show me the changes between the remote master
branch and my master
branch).
remotes/origin/HEAD
is the default branch
for the remote named origin
. This lets you simply say origin
instead of origin/master
.
Short answer for dummies like me (stolen from Torek):
- origin/master is "where master was over there last time I checked"
- master is "where master is over here based on what I have been doing"