TL;DR: just use git branch -r or git branch -a (after git fetch to update). It's not at all clear why you've been seeing remote-tracking branches without these flags (perhaps you have been using a GUI that shows them automatically?).
You do, however, have at least one small misconception built in to your question—which is not surprising; this particular part of Git is tricky at first.
There are, in fact, three sets of branch names involved in this question.
git remote show origin shows me all branches.
Not exactly. Let's back up a bit, and define two sets (or classes, or whatever word you like to group them) of branches. Git provides:
Your regular, ordinary, local branches. These are what git branch shows, when used with no arguments and flags.
$ git branch
diff-merge-base
* master
precious
stash-exp
The word "branch" often means one of these: a name that, when fed to git rev-parse, resolves to a commit ID:
$ git rev-parse diff-merge-base
2d0cc5001c1a88995727521d4ef77f7a4acc4e14
and whose full name starts with refs/heads/:
$ git rev-parse --symbolic-full-name diff-merge-base
refs/heads/diff-merge-base
Your remote-tracking branches. These are what git branch -r shows:
$ git branch -r
origin/HEAD -> origin/master
origin/maint
origin/master
origin/next
origin/pu
origin/todo
The key difference between these is that your local branches are your names to manipulate however you like, while your remote-tracking branches are your names that Git automatically slaves to something else. It is possible for you to manipulate them yourself, but it's not profitable, as their intent is to remember some other Git's branch names (and corresponding SHA-1 values).
Note that feeding a remote-tracking branch name to git rev-parse also works, and you can get its symbolic-full-name as well: this simply begins with refs/remotes/, followed by the name of the remote, followed by the local name as seen if you're the Git running on the remote. Hence:
$ git rev-parse --symbolic-full-name origin/master
refs/remotes/origin/master
means that my Git's origin/master is my Git's memory of what master meant, on origin, the last time had my Git call up origin and fetch—i.e., update—from them.
git remote (sometimes) actually calls up the remote Git
Remember that there are two (or sometimes even more) Git version-control databases involved any time you fetch or push commits. So you can look at your information, or you can ask your Git to call up their Git, over the Internet-phone, and query them about their information. They, too, may have local branches, and even remote-tracking branches, of their own. (Usually, for situations like this, they have only local branches.)
For illustration purposes, let me delete one of my own remote-tracking branches (this is pretty harmless since I will run git fetch in a moment to restore it):
$ git branch -r -d origin/pu
Deleted remote-tracking branch origin/pu (was 7c79844).
Now if I run git branch -r I will no longer have an origin/pu: my Git no longer has that as a remote-tracking branch. But their Git, over on origin, still has a local branch named pu, so:
$ git remote show origin
* remote origin
Fetch URL: git://git.kernel.org/pub/scm/git/git.git
Push URL: git://git.kernel.org/pub/scm/git/git.git
HEAD branch: master
Remote branches:
maint tracked
master tracked
next tracked
pu new (next fetch will store in remotes/origin)
todo tracked
Local branches configured for 'git pull':
master merges with remote master
stash-exp merges with remote master
Local ref configured for 'git push':
master pushes to master (local out of date)
When I run git remote show origin, my Git calls up their Git (this happens to be a copy of the Git repository for Git—there's another one on github.com that is probably more appropriate these days) and gets from them a list of all their branches. I already have most of them as my own "remote-tracking branches", but I deleted pu, so it shows as "new".
A similar command, git ls-remote, also calls up the other Git and queries it, but shows you more: it shows you the commit hash that goes with each branch (and the object hash for each tag as well). There are a lot of tags, so let me restrict this to just one branch:
$ git ls-remote origin master
e05806da9ec4aff8adfed142ab2a2b3b02e33c8c refs/heads/master
In both these cases, your Git (or my Git) calls up their Git and gets information from them, but it merely displays it, rather than saving it. To save the information, we must run git fetch. I have not run this in a little while, so:
$ git fetch origin
remote: Counting objects: 2064, done.
remote: Compressing objects: 100% (1294/1294), done.
remote: Total 2064 (delta 1383), reused 1118 (delta 767)
Receiving objects: 100% (2064/2064), 2.12 MiB | 2.29 MiB/s, done.
Resolving deltas: 100% (1383/1383), done.
From git://git.kernel.org/pub/scm/git/git
de2efeb..e05806d master -> origin/master
3074f94..c69c2f5 next -> origin/next
* [new branch] pu -> origin/pu
1a46792..2135c1c todo -> origin/todo
This git fetch did the same thing as git remote show and git ls-remote, but then also did more things: it collected the objects I need to complete my repository, then updated my remote-tracking branch names to correspond to the branch names in their repository.
This is why I regained origin/pu: they still have a pu, and I discarded mine, so I obtained theirs and now have one again.
This is also why I updated all the others except maint: it's been long enough that they have all been updated. My origin/master used to refer to commit de2efeb, but now it refers to e05806d, which is the same ID we saw above when we ran git ls-remote. (This means they did not update their master in the several minutes it took me to type all this in. Imagine that, billions of nanoseconds have gone by without an update! :-) )
(Note that git remote show -n origin skips the phoning-up of origin, and simply shows you what your Git has recorded. Several other git remote commands also work locally; consult the documentation for specifics.)
Summary
To recap, then, there are three sets of branch names involved here:
- Your local branches;
- Your remote-tracking branches; and
- Their branches (in the remote Git).
The last set of branch names don't matter, most of the time. Most of the time, you work in your own repository. There's only one Git involved, and it's yours. Their Git, which has its own branches, is right out of the picture.
But sometimes—ah, such times!—sometimes, you must connect your Git to another Git. Now their names matter! The really tricky thing here is that your names don't have to match their names at all. There's no hard and fast reason your master must correspond to their master—but your Git will copy their master to your origin/master, so it saves a lot of brain cells if your names and their names do match up. You can work around this (in multiple different ways), but don't do it until you have a situation that really calls for it (with multiple remotes that use conflicting branch names—this almost never happens).
What about git checkout blah?
You noted above that:
If I do a git checkout on one of [their branch names that I don't see in git branch output], it pulls the branch down locally and swaps to it.
Let's say that you have run git branch -r (rather than git remote show origin) and seen a branch named origin/zorg. Let's also say you don't already have a (local) branch named zorg. You run:
$ git checkout zorg
and your Git says:
Branch zorg set up to track remote branch zorg from origin.
Switched to a new branch 'zorg'
Your Git hasn't "pulled down" anything here. What it's done is to create a new local branch name, zorg, pointing to the same commit—the same big ugly SHA-1 hash ID—as origin/zorg. That commit was already in your repository, ready to be checked out any time, and in fact you could have done:
$ git checkout origin/zorg
to look at it—but that would give you what Git calls a "detached HEAD".
What's going on here is that in Git, a branch name is merely a moveable pointer to one specific commit. The git checkout command, when used this way, does two things: check out the one specific commit (into the work-tree), and, switch your Git's notion of the "current branch name". When you git checkout an existing, local, ordinary branch name, Git checks out the one commit in question, and puts you "on the branch", as git status will say:
$ git status
On branch master
When you git checkout any commit by something that's not a simple branch name, Git still checks out the one commit, but takes you off of any branch, i.e., gives you a "detached HEAD".
We know from the above that origin/master is (now) commit e05806da9ec4aff8adfed142ab2a2b3b02e33c8c, so:
$ git checkout origin/master
or:
$ git checkout e05806da9ec4aff8adfed142ab2a2b3b02e33c8c
both do the same thing. Since origin/master is not a local branch, I end up with:
$ git status
HEAD detached at e05806d
(or sometimes HEAD detached at origin/master).
Hence, what git checkout does is attempt to convert the name you gave it to a branch name. If that fails, git checkout has this extra built-in feature: it searches through all your remote-tracking branches to see if there's exactly one that "mostly matches" the name. So git checkout zorg checks for a local branch named zorg, fails to find it, then searches all your remote-tracking branches for one that also matches zorg. There is in fact exactly one—origin/zo
