Why do I need to explicitly push a new branch?

Asked 13/6, 2013 at 20:21 Answered 4/11, 2019 at 16:27

206

I am new in git and I am practicing. I created a local branch but I saw that when I did git push my branch was not uploaded to the repository. I had to actually do: git push -u origin --all.
Why is this? Isn't a branch a new change to be pushed by default? Why do I need to run the second command?

Suffumigate answered 13/6, 2013 at 20:21 Comment(2)

Note that this is configurable (setting push.default, see man git-config). If you do git config --add push.default current, then git push will automatically create the branch in the remote repo if necessary. Why this is not the default is explained in the answers. – Sequester 13/6, 2013 at 21:31

@Sequester I agree. For the other policies 'current' and 'upstream', see my older answer https://mcmap.net/q/13444/-git-push-current-vs-push-upstream-tracking. – Johppah 13/6, 2013 at 21:46

271

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 master branch 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.

Johppah answered 13/6, 2013 at 20:52 Comment(9)

After this point, the next git push also expects the branch to already exist? – Suffumigate 13/6, 2013 at 21:29

Yes. It will push any updates to that branch to upstream repository. – Status 13/6, 2013 at 21:30

@Suffumigate yes, because of the new default push policy 'simple': push to any recorded upstream branch, if that upstream branch has the same name as the local one. A simple git push will be enough. – Johppah 13/6, 2013 at 21:38

Suppose i had used git push origin master for the first time, how do i subsequently mark origin/master as a remote tracking branch? Can i still use git push -u origin master when the remote branch already exists and has been pushed to before? – Ceilidh 23/11, 2014 at 5:50

How to remember this solution: Just follow the helpful git output after an unsuccessful git push. It proposes git push --set-upstream origin master, which is the long version for git push -u origin master. – Softspoken 15/1, 2015 at 1:53

@Johppah the link seems to say it doesn't apply for Git above v1.7. Is it ok to use a non-bare repo with Git 2.3? – Hooper 12/11, 2015 at 22:12

@ButtleButkus Git 2.3 is actually ok: see https://mcmap.net/q/11336/-how-to-push-to-a-non-bare-git-repository – Johppah 12/11, 2015 at 22:14

For the questioner's more general case of a new branch 'new_branch', you would use git push --set-upstream origin new_branch or git push -u origin new_branch for short. The -all that the questioner used bypassed naming a specific new branch by including all branches. This is covered by +Klas Mellbourn in his answer. – Blackfellow 14/12, 2015 at 15:53

The -u is shorthand for the suggestion that git (ver 2.20) gives you when you try to push a branch upstream and there is no matching branch. It's shorthand for --set-upstream – Hysteria 19/7, 2019 at 2:2

121

You don't, see below

I find this 'feature' rather annoying since I'm not trying to launch rockets to the moon, just push my damn branch. You probably do too or else you wouldn't be here!

Here is the fix: if you want it to implicitly push for the current branch regardless of if that branch exists on origin just issue this command once and you will never have to again anywhere:

git config --global push.default current

So if you make branches like this:

git checkout -b my-new-branch

and then make some commits and then do a

git push -u

to get them out to origin (being on that branch) and it will create said branch for you if it doesn't exist.

Note the -u bit makes sure they are linked if you were to pull later on from said branch. If you have no plans to pull the branch later (or are okay with another one liner if you do) -u is not necessary.

Fifteenth answered 13/8, 2015 at 22:22 Comment(5)

When I do this, if I do a git pull, immediately after - the two branches aren't linked. :( – Moua 26/1, 2016 at 10:23

this is the only answer that fixed my problem. – Shuffleboard 18/5, 2017 at 9:34

To link them, use git push -u – Blintze 28/10, 2017 at 1:6

Thanks! This answer ought to be accepted as the quick-and-'dirty' solution. I'm pretty sure it's closest to what OP's intention. – Marlow 19/7, 2018 at 23:6

> I'm not trying to launch rockets to the moon. -- YES. – Mendy 4/3, 2019 at 23:0

Output of git push when pushing a new branch

> git checkout -b new_branch
Switched to a new branch 'new_branch'
> git push
fatal: The current branch new_branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new_branch

A simple git push assumes that there already exists a remote branch that the current local branch is tracking. If no such remote branch exists, and you want to create it, you must specify that using the -u (short form of --set-upstream) flag.

Why this is so? I guess the implementers felt that creating a branch on the remote is such a major action that it should be hard to do it by mistake. git push is something you do all the time.

"Isn't a branch a new change to be pushed by default?" I would say that "a change" in Git is a commit. A branch is a pointer to a commit. To me it makes more sense to think of a push as something that pushes commits over to the other repositories. Which commits are pushed is determined by what branch you are on and the tracking relationship of that branch to branches on the remote.

You can read more about tracking branches in the Remote Branches chapter of the Pro Git book.

Mistymisunderstand answered 13/6, 2013 at 20:25 Comment(10)

I did not get a fatal but I had already done a commit in the branch.Does this matter? – Suffumigate 13/6, 2013 at 20:32

@Suffumigate no it does not matter. The commit is safe in your repository, and the git push -u origin copied it over to the remote repository. – Mistymisunderstand 13/6, 2013 at 20:35

No I mean the fact that I did not get a fatal msg like the one that you mention in the answer.Does this difference depend on the fact that I committed something to the branch? – Suffumigate 13/6, 2013 at 20:36

@Suffumigate I don't know why you did not get the fatal message. I would guess that the difference depends on exactly what git implementation you are using. My output is from 1.8.1.msysgit.1 running on Windows 8. – Mistymisunderstand 13/6, 2013 at 20:38

I have the same version but on Vista – Suffumigate 13/6, 2013 at 20:40

@Suffumigate I get the fatal message even if I make a commit. – Mistymisunderstand 13/6, 2013 at 20:42

If I checkout -b name and commit a file my HEAD is in name.If I do git push I get:

warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: etc

and then Everything up-to-date – Suffumigate 13/6, 2013 at 20:46

@Suffumigate You can avoid that message by doing git config --global push.default simple. The reason you got Everything up-to-date must be that there already was a name branch on the remote that is now tracked by your local name branch. – Mistymisunderstand 13/6, 2013 at 20:49

Ok. But why is it not fatal? – Suffumigate 13/6, 2013 at 20:50

let us continue this discussion in chat – Mistymisunderstand 13/6, 2013 at 20:51

I couldn't find a rationale by the original developers this quickly, but I can give you an educated guess based on a few years of Git experience.

No, not every branch is something you want to push to the outside world. It might represent a private experiment.

Moreover, where should git push send all the branches? Git can work with multiple remotes and you may want to have different sets of branches on each. E.g. a central project GitHub repo may have release branches; a GitHub fork may have topic branches for review; and a local Git server may have branches containing local configuration. If git push would push all branches to the remote that the current branch tracks, this kind of scheme would be easy to screw up.

Syrupy answered 13/6, 2013 at 20:39 Comment(2)

1)It might represent a private experiment.Ok but what is the big deal? The "main" branch that everyone is working i.e. master is not affected. Unless you mean to keep the source code hidden 2)git push, without a remote, pushes to the current branch's remote I lost you here :( – Suffumigate 13/6, 2013 at 20:43

@Cratylus: 1) in a project with dozens of developers who all branch ad lib, you're going to get very messy repos. I work on such projects, and I wouldn't want to git fetch hundreds of half-working branches every time. 2) I'm referring to git push's default behavior. It pushes to the remote that the current branch is tracking, if any. – Syrupy 13/6, 2013 at 20:49

HEAD is short for current branch so git push -u origin HEAD works. Now to avoid this typing everytime I use alias:

git config --global alias.pp 'push -u origin HEAD'

After this, everytime I want to push branch created via git -b branch I can push it using:

git pp

Hope this saves time for someone!

Vulture answered 29/9, 2017 at 6:34 Comment(0)

At first check

Step-1: git remote -v
//if found git initialize then remove or skip step-2

Step-2: git remote rm origin
//Then configure your email address globally git

Step-3: git config --global user.email "[email protected]"

Step-4: git initial

Step-5: git commit -m "Initial Project"
//If already add project repo then skip step-6

Step-6: git remote add origin %repo link from bitbucket.org%

Step-7: git push -u origin master

Hypopituitarism answered 18/12, 2017 at 8:42 Comment(0)

I just experienced a further permutation of this issue.

I had a branch named feat/XYZ-1234-some-description because I was working on Jira issue 1234. During the work I created a new Jira issue to track a smaller piece of work, and when I came to push I decided to push to a branch name with this new issue number in:

git push -u origin feat/XYZ-5678-a-different-description # failed

This gave me the error being discussed in this SO thread. But since I was trying to push to a different branch name from my current branch, my problem was different to the one described here. I ended up renaming my local branch before I could push it:

git branch -m feat/XYZ-1234-some-description feat/XYZ-5678-a-different-description
git push -u origin feat/XYZ-5678-a-different-description # now works

After a bit more reading around I realised that I could have set a src on the git push, either to the current branch name, or just HEAD if appropriate:

git push -u origin feat/XYZ-1234-some-description:feat/XYZ-5678-a-different-description # also works

Osswald answered 4/11, 2019 at 16:27 Comment(0)

-1

If you enable to push new changes from your new branch first time. And getting below error:

*git push -f
fatal: The current branch Coding_Preparation has no upstream branch.

To push the current branch and set the remote as upstream, use

git push -u origin new_branch_name


** Successful Result:** 
 git push -u origin Coding_Preparation
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 599 bytes | 599.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'Coding_Preparation' on GitHub by visiting: ...
 * [new branch]      Coding_Preparation -> Coding_Preparation
Branch 'Coding_Preparation' set up to track remote branch 'Coding_Preparation' from 'origin'.

Heimdall answered 2/9, 2019 at 14:18 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags