Git branch not returning any results

This question has some duplicate-links to it now, so I thought I would expand a bit on neevek's accepted answer. Specifically, we can say why the concept of an unborn branch exists.

Let's start with this: while Git has branches, and commits have files in them, Git isn't really about branches or files. Git is really all about commits.

The commits in a Git repository are numbered, but the numbers are kind of weird. Instead of simple counting numbers—commit #1, followed by #2, then #3, and so on—each number is a random-looking hash ID. These aren't actually random at all: right now they're all SHA-1 hashes, although Git is gradually acquiring the ability to use other hashes, starting with SHA-256. But in any case, each commit gets a unique number, which is typically shortened to a still-random-looking sequence of letters-and-digits like a1f9371 or 053af72 or whatever.

When you make a new repository (with git init, or by cloning an empty repository), there are no commits in it yet. This should make perfect sense: commits come into existence by your action of creating a commit, or, when you use git clone, by copying from some other, existing Git repository, all of the commits it has.

The tricky part with a branch name is that the way a branch name works is that it holds the hash ID of one commit. We won't go into any detail as to how this lets Git find all the previous commits, but it does. The point here is that for a branch name to exist, it must hold the hash ID of some existing commit.

Hash IDs are not predictable. Among other things, the hash ID of any new commit you make depends on precisely when, to the second, you make it. So there's no way to know in advance what the random-looking hash ID of the very first commit will be.

Since a branch name has to hold the hash ID of some valid, existing commit, and an empty repository has no commits, no branch name is allowed to exist yet either! The empty repository therefore has no branches (and of course no commits). And yet, in a new repository, you are on a branch. How can you be on a branch that does not exist?

Git's answer to this dilemma is to put you on an unborn branch. Your current branch is this unborn branch. You can pick any other unborn-branch name you like, using git checkout -b to switch to that other unborn branch name. The previous unborn name still does not exist, and is now forgotten.

When you make the very first commit in this new repository, now branch names can exist. Git creates the unborn branch's name as a valid branch name, and stores in that name the hash ID of the new commit you just created. And, now that one commit exists, you can now create as many branch names as you like. All of them will necessarily have to hold that one commit's hash ID, until you create a second commit, when each name can hold either the first commit's ID, or the second commit's. But in that special state, when there are no commits at all, there can be no branch names either.

Note that besides this special case, git checkout lets you create a new unborn branch. The flag for this is --orphan (rather than --unborn), but what git checkout --orphan name does is put you into the unborn-branch state, with the current branch name being name, so that the next commit you create will create that branch's name. This will produce a new branch whose history consists only of the single new commit, so that the new branch's history is not related to the history of any other branch name in this same repository. This mode is rarely of any particular use, but it's always available, because this unborn branch state is required for new, empty repositories.

That's because you have not yet committed anything, when you do git checkout -b test, git modifies content of the .git/HEAD file from ref: refs/heads/master to ref: refs/heads/test, which actually points to nothing. Only after you make a commit will git create the test refs for you and you will find a .git/refs/heads/test file, which contains the hash of the commit you just made.