How can I show all the branches in a repository?

As the documentation of git branch explains, git branch --all (or -a) lists all the branches from the local repository, both the local and the remote tracking branches.

A Git branch is just a pointer to a commit. A new repository (just created with git init) does not contain any commits. The current branch on a new repo is master but the master branch does not actually exist. In fact, a new repository does not contain any branch.

The master branch is created when the first commit is created. Or when it is pulled from a remote repository.

Since you didn't create any commit and also didn't pull the master branch, it does not exist in your repo. Both commands you listed show you this thing.

git branch -a is the one you want to use to list the branches.

git show-branch is designed to be used by scripts and GUI tools.

In a freshly-created git repository, until something gets pushed onto the master branch the repository is actually in a slightly "invalid" state. The HEAD is set to point to the master branch, but the master branch does not exist in the repository itself.

A git branch is synonymous with the commit at the HEAD of the branch. A branch is just an alias for one of the commits in the repository. That's all it is. Nothing more, nothing less. A git init initializes the repository with the HEAD indicating that it's the HEAD of a master branch, but there is no actual master branch in the repository.

Once a first commit is made, the commit gets pushed into the repository, and the git branch gets repointed to the commit in question. This happens with every commit, not just the initial commit, but now, after the initial commit, everything is in order.

What you're seeing, with that error message, is the end result of git's current, temporary, confused state. If you do a git checkout mongodbutils, all traces of the master branch will be gone. Of course git show will then show you the HEAD commit of this branch, and no error message, and git branch will report no evidence of the master branch, either.

As Sam Varshavchik answered, you're in a peculiar state. I would not, however, call it an invalid state.

You can achieve this same state any time you like, in any other Git repository, using git checkout --orphan:

$ git status
On branch master
Your branch is behind 'origin/master' by 98 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean
$ git checkout --orphan asdf
Switched to a new branch 'asdf'
$ git status | head -3
On branch asdf

No commits yet
$ git branch | grep asdf
$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 98 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

What's going on here is that you can be on a branch that does not exist.

In a new, empty repository just created by git init, that is always the case. A branch exists because a reference whose name starts with refs/heads/ contains the hash ID of a valid commit.

In a new, empty repository, there are no valid commits. Therefore the branch master cannot exist. Yet, you're still on branch master.

This paradox arises because a symbolic reference can name a branch that does not exist. HEAD is normally a symbolic reference (except, of course, when it's "detached"). That is, HEAD contains the name of a branch. That branch does not have to exist! If it does not, Git says that you are on an unborn branch, or sometimes that you have an orphan branch, or just a branch with "no commits yet".

The git branch command enumerates the branches that exist, so it skips over this unborn branch, if you're in this peculiar state. (Should git branch enumerate this extra, nonexistent branch? That's a reasonable question to ask. Git currently says no, but maybe someday the Git authors will change their minds.)

To see which branch name HEAD is attached to, use git symbolic-ref HEAD. If you're in detached HEAD state, the command will fail (with an error message), so you know that HEAD is not attached to any branch name. Otherwise, you'll get the branch name:

$ git symbolic-ref HEAD
refs/heads/asdf

even if the branch name does not exist.

When in orphaned state, the next commit will be a root commit

When you are in this peculiar state of being on a branch that does not exist, this has an important effect on the next git commit that you run.

As always, git commit will build its new commit's content from whatever is in the index at the time you run git commit. Using git checkout --orphan leaves the index undisturbed, which is why I ran git status | head -3 above: the index is still full of all the files from the tip of master, in my case:

$ git status --short --branch | head -5
## No commits yet on asdf
A  .clang-format
A  .editorconfig
A  .gitattributes
A  .github/CONTRIBUTING.md

I won't actually run git commit here, but if I did, Git would make a new commit now, using the index contents as the snapshot, collecting a log message from me, using my name as author and committer, and so on. The parents of the new commit, however, would be none at all. So the new commit would be a new root commit.

In a new, totally-empty repository, this is what you want for master: the first commit is a—well, the—root commit, which creates master, so that now you have a master branch. This is also what it means to use git checkout --orphan: that you'd like your next commit to be another root commit.

This is not particularly useful except in special circumstances, such as when doing git rebase -i --root, where Git wants to do this internally.