I a very very beginner with git. I've read that git push --set-upstream origin master must be executed only once - when repo is empty.
However, I forgot and pushed with --set-upstream origin master second time. Now, when I do git branch -a I get
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
What does it mean and what I should do now?
I a very very beginner with git. I've read that
git push --set-upstream origin mastermust be executed only once - when repo is empty.
That's not quite right, in two different ways. One of them is that this is OK:
However, I forgot and pushed with
--set-upstream origin mastersecond time.
You can do this as many times as you like.
The second flaw in the original claim is that you never have to do it even once. It's both convenient and a good idea to do it once, on the first git push, but it's not a requirement.1 Moreover, it's a good idea to do it once for each new-to-them branch,2 not just if the upstream repository is empty. That is, "first push" does not mean "first push ever" but rather "first push per new branch".
Every time you use the -u or --set-upstream option with git push, you set, or re-set (i.e., do not change), or even do change, the upstream setting for the branch you just pushed. Pushing branch B to the remote named origin creates or updates your origin/B remote-tracking branch,3 and then sets B's upstream to origin/B. If it was already set like that, no problem! If it was not set at all, now it's set: yay! If it was set differently, now it's set to origin/B. If that's how you want it set: yay! This is only bad if that's not how you want it set (which seems pretty unlikely).
To understand why you would want to set or change the upstream, see this answer to a related question. Note that you can also unset the upstream of any given branch.
To see more history, of how this used to work in the bad old days with Git version 1.7 and earlier, see this question and this one.
Dhiraj's answer explains what you are seeing now.
1Using -u is not a requirement per se. But, if the other Git repository, the one to which you are pushing, does not have a branch of the same name, and your push.default configuration is simple, your alternative to git push -u origin master is git push origin master:master, i.e., you would have to specify the branch name twice. Writing -u once is shorter, and sets your master's upstream to the newly-created origin/master, which is a good thing—so it's shorter and better to use -u once, but it is not required.
2When you run git push or git fetch—or git pull, which just runs git fetch and then a second Git command—you have your Git call up another Git. That other Git has its own branches. Those branches have their own commits, which may or may not match your commits on your branches. Obviously, a new, completely-empty repository has no commits (and therefore no branches),4 but if you have created a new branch named zorg, their Git probably does not yet have a zorg: the branch will be new to them.
3Your remote-tracking branches—such as origin/master—are a way for your Git to remember, for your convenience, what your Git got from their (origin's) Git regarding their branches, the last time you ran git fetch or git push to origin. This is what they are for. Use git fetch (or git remote update) to update them all, from time to time, whenever you think they might have changed and you want to find out.
4Philosophical question: what does it mean for a branch to exist, yet have no commits? Is there such thing as an "empty branch"? (The answer for Git is mostly no, there is no such thing, but there are other version control systems—and I just said "mostly"....)
At GitHub, you can select which branch is checked out by default (i.e. when you clone). By default, origin/HEAD will point at that.
Please refer this link for more details Why is "origin/HEAD" shown when running "git branch -r"?
