fr3dch3n's answer is correct—running git status will tell you which branch you're on—but doesn't address why git branch shows you nothing at all. The reason is that you are in a special state.
You just created a new, empty repository—a repository with no commits at all—by doing your git init.
Now, the thing about branch names in Git is that they always—always—point to one specific commit. But you have no commits at all, so how can a branch name like master or aaa point to one?
The answer is that it can't, so it doesn't, and Git achieves that by not creating the branch yet. You are, quite simply, on a branch that doesn't exist.
This special state has to occur when the repository is new and completely empty of commits, but it also occurs if you use git checkout --orphan <newbranch>. This puts you on the new branch witihout first creating the branch, so that the new branch doesn't exist.
When a branch doesn't exist, yet you're "on" that branch in git status terms, and you run git commit, Git creates a new commit as usual,1 and at the end of the process, Git updates the current branch name so that it points to the new commit it just made. If the branch didn't exist before, now it does!
So, in a new, empty repository, the branch you're "on" doesn't exist, and switching to another new branch with git checkout -b puts you on the other new branch that continues not to exist. The branch that you were on, that didn't exist, simply vanishes into thin air: it was never there, it was just a phantom that you were "on", and now you're on a new and different phantom.
(The same thing happens with git checkout --orphan <newbranch> later: it puts you on this sort of ghostly non-existent branch, and if you then switch to a different new branch, you continue to be on a ghostly non-existent branch. Running git checkout master, or using the name of any actual existing branch, will switch you back to the existing branch, assuming the git checkout itself succeeds.)
1The git commit process works like this, although the precise order of various steps is somewhat changeable, and options like git commit --only <files> make bigger changes.
- Make sure it looks OK to commit (do any pre-commit testing required, including running a pre-commit hook).
- Turn the current index contents into at least one tree object, making a snapshot of all of the files ("blobs") that are in the index now. (This is the
git write-tree command.)
- Gather together your name, email, and a timestamp as "author" and again as "committer" for this commit. Add on the commit log message.
- Figure out which commit(s) are the parent(s) for this commit.
- Make the new commit object (
git commit-tree).
- Update the current branch name so that it points to the new commit.
It's step 6 that actually creates the branch, in this special "branch that is yet to be created" condition.
Note that in step 4, "figure out parents", Git notices this same "branch that is yet to be created" condition. The result of this condition is that there is no parent for the new commit: the new commit is a root commit. Normally, though, step 4 reads HEAD with the goal of find the hash ID of the current commit: HEAD contains the branch name, and the branch does exist and contains the current commit hash ID.
When committing the merge result after resolving conflicts from git merge, step 4 uses a trace file that git merge leaves behind, to determine the extra parent commit hash (normal merge) or hashes ("octopus" merge). The current or HEAD or @ commit is still, as usual, the first parent.
