The actual reason is that, in a new repo (git init), there is no branch (no master, no branch at all, zero branches)
So when you are pushing for the first time to an empty upstream repo (generally a bare one), that upstream repo has no branch of the same name.
And:
- 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 (origin) ‘master‘ (upstream branch): bad.
That is why it is recommended, for the first push, to do a:
git push -u origin master
Or, using Git 2.37 and the new global option push.autoSetupRemote :
git config --global push.autoSetupRemote true
git push
That will record origin/master as a remote tracking branch, and will enable the next push to automatically push master to origin/master.
git checkout master
# Git 2.23+
git switch master
git push
And that will work too with push policies ‘current‘ or ‘upstream‘.
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.