The question is: Since I am able to download my GitHub repo via Git even though I haven't uploaded the repo to Git, and since there seems to be a .git file, does that mean that my repo is automatically uploaded ...
(emphasis mine)
No. However, the answer to the question you asked in the subject line is "yes": creating a GitHub repository creates a Git repository.
The tricky part here is that a GitHub repository is a Git repository. What GitHub adds (their "added value" as a service) is—well, more than one thing, so let's say includes rather than is—that the repository they create is stored on their computers, where it gets backed up, and is accessible from all over the web, and so on.
They—GitHub—also add a bunch of communications layering, and things like one-button "pull requests", and forks, and so on. But it all starts with them creating a Git repository.
The thing is, their Git repository is, at this point, totally independent of your Git repository, if you even have one yet!
The way two different (independent) Git repositories talk to each other is, at least normally, to use git fetch and/or git push. These Git commands tell your Git to call up some other Git, usually via some http or https or ssh address. Once your Git is talking to that other Git via whatever this communications channel may be—I like to call it a telephone conversation, which might be meaningful for those folks who use their smartphones to make actual phone calls :-) —your Git and their Git exchange information as to who has which commits, and one Git (the sender) sends commits and other objects to the other Git (the receiver).
If you don't have a Git repository at all yet, you can use a four-step process:
- create a new, totally-empty repository;
- add a remote (usually named
origin) that stores a URL like https://github.com/path/to/repo.git;
- run
git fetch in this new empty repository to collect all the commits in the other Git that answers the Internet-phone at that https "phone number"; and last
- run
git checkout master to create a new branch named master in your new repository using the same commit found by the name origin/master that step 3 created in your repository, based on what their Git has in their master.
Or, you can run git clone, which does those steps for you.
Either way, now there are two Git repositories.
There's one other thing to watch out for, though.
GitHub can create a totally-empty repository, or one with 1 commit
When you use the "create repository" button on the GitHub web interface, that does create a Git repository there. You now choose whether to create it with a README file and/or a .gitignore file and/or a LICENSE file, using clicky boxes and pulldown menu buttons.
In order to create a repository with files, GitHub must actually start by creating a completely empty repository, then immediately add a single commit whose contents are the files you chose.
They claim:
This will let you immediately clone the repository to your computer. Skip this step if you’re importing an existing repository.
but that's not really true. You can immediately clone the empty repository, too. The problem is that an empty repository behaves rather oddly.
Now, if you use git init to make your own repositories, those are also empty. They behave rather oddly too, but you may not have noticed, because as soon as you make your first commit, they begin behaving normally ... and any oddness can be written off pretty easily. This is less so for the git clone command, which really wants to end with a git checkout step.
Still, you can clone an empty repository. The result is another empty repository. You can then create a first commit here, and use git push to send it back to the (still-empty) repository on GitHub. Once you create a commit in your clone, it's no longer empty and it starts behaving normally; when you run git push, your Git calls up the Git on GitHub at the stored "phone number", sends them your commit(s), and has them create a master branch, or whatever branch you actually created and pushed, and now their repository also starts behaving normally.
What if you have them make 1 commit, but you make your own first commit?
If you think about the above, you will see that you could have GitHub create a repository and put one commit in it, and then you could git init your own repository and put your own first commit in it. Then you can git add origin https://github.com/... to set your Git up to call their Git up, and try running git fetch.
This will work just fine. Your Git will call up their Git and have their Git send you their commits, which will be their one single root commit with the readme, ignore, and/or license files. Your Git will record that commit's hash ID under your Git's origin/master name.
Meanwhile, though, your own Git has your first commit recorded under your master name. Your first commit has whatever you put in it—maybe different files than the up-to-three GitHub will create for you.
The curious things about this is that both of these commits are root commits. They have their one commit, which is unrelated to your one commit; and now you have their one commit, and your one commit.
You can ask your Git to merge these two commits. Some versions of Git will do that without question. Newer versions (2.9 or later) will object: Hey, your master and their origin/master seem unrelated! To get these newer Gits to merge these unrelated histories, you must add the --allow-unrelated-histories option. For more about this, see VonC's answer to a related question.
