Git has a steep learning curve, like climbing a mountain all at once in a few hours or days. This is both the bad news (it's a lot of work!) and the good news (you're on top of a mountain in just a few hours or days!).
When you use git init to create a new repository (git init has a completely different function when you use it on an existing repository), you get a new, empty repository with no commits and no branches. Nonetheless, you're still "on" some branch. You might wonder how you can be on a branch that doesn't exist. Well, that's one of the reasons Git has such a steep learning curve. (The fact that git init does two almost-completely different things—create a new repository, or "reinitialize" an existing one, in which case, usually nothing at all happens—is another of those reasons.)
When you're in this funny "on a branch that does not exist" state, the next commit you make will create the branch. So it's your initial commit that actually creates the branch. That's why Git said:
[main (root-commit) d09db1a] test
The (root-commit) is the clue that this just created the branch; the main part is the name of the branch it just created, and d09db1a is the hash ID or OID of the new commit (abbreviated, though: the actual hash IDs are even longer and quite random-looking).
Creating the branch takes you out of the weird state. For this reason, GitHub and other hosting sites will often create a new repository for you and immediately create one commit so that the new repository can have a branch. You can clone a totally-empty repository, one with no commits and no branches at all, but the effect is as weird as the fact that you're on a branch when there is no branch. This is why GitHub really like to make your first commit for you.
The problem in this case is that in Git, the commits are the history: history is nothing more or less than the set of commits in the repository. Commits normally have parent/child relationships: the very first commit ever is the root commit—that's the phrase we just saw again—and then every commit after that is a child or grand-child or great-grand-child or great-great-... etc of that root commit.
But when you let GitHub create the first commit, and then you also create the first commit, well, now you have two first commits that aren't related. And, alas, Git doesn't like to "marry" (merge) unrelated commits. (Perhaps the "must marry your cousin" thing also explains some of Git's weirdness. )
This is why, as VonC says, if you plan to make the first commit yourself, locally, you shouldn't let GitHub make the first commit too. GitHub give you some clicky check-boxes (well, radio buttons) on the web page when you go to create a new repository on GitHub.
Anyway, this gets you on to the next parts of the steep learning curve. A relatively new one of these is now the whole master vs main thing. When you create that first commit, that creates the branch you were on, so that it now exists. The name that this creates is the one you chose at git init time, using the -b option (see the git init documentation). But you didn't use -b, so you got some default. The default was master. In some versions and distributions of Git, the default still is master. In other versions, the default is now main. This situation has been going on for a few years now. It's not clear if it will ever resolve completely (there are still people out there using Git 1.7 and 1.8 and those are more than ten years old—well, 1.8 is just under 10 years old right now, but that won't last).
Two down, many to go: you've hit two oddities already (i.e., why a truly-empty repository is weird and slightly complicated, and main-vs-master). You have a lot left to go. "Upstreams" are one of these, but they're not as tricky as the whole idea of "repository clones" in the first place. The thing to remember here is that Git is really about commits, and commits are really found by their hash IDs. Things like branch names are mostly for humans, not so much for Git itself.
