The actual reason is that, in a new repo (git init), there is no branch (no
master, no branch at all, zero branches)
- the default push policy was '
matching' (push all the branches of the same name, creating them if they don't exist),
- the default push policy is now '
simple' (push only the current branch, and only if it has a similarly named remote tracking branch on upstream, since git 1.7.11)
In both cases, since the upstream empty repo has no branch:
- there is no matching named branch yet
- there is no upstream branch at all (with or without the same name! Tracking or not)
That means your local first push has no idea:
- where to push
- what to push (since it cannot find any upstream branch being either recorded as a remote tracking branch, and/or having the same name)
So you need at least to do a:
git push origin master
But if you do only that, you:
- will create an upstream
masterbranch on the upstream (now non-empty repo): good.
- won't record that the local branch '
master' needs to be pushed to upstream (
master' (upstream branch): bad.
That is why it is recommended, for the first push, to do a:
git push -u origin master
That will record
origin/master as a remote tracking branch, and will enable the next push to automatically push
git checkout master git push
And that will work too with push policies '
current' or '
In each case, after the initial
git push -u origin master, a simple git push will be enough to continue pushing master to the right upstream branch.