Git: 'The Current Branch Has No Upstream Branch' - How to Fix It

This error means you are pushing a brand-new local branch that does not yet exist on the remote, so Git does not know where to send it. The fix is one command:

git push -u origin feature-login

That pushes the branch to your remote (origin) and records it as the upstream, so from then on a plain git push and git pull just work on that branch.

The full error

When you create a local branch, commit on it, and run git push with no arguments, Git stops with this:

fatal: The current branch feature-login has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin feature-login

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

Note that Git already tells you the exact command to run. The message is not a bug or a misconfiguration. It is Git refusing to guess where a never-pushed branch should go.

What "upstream branch" actually means

A local branch and a remote branch are separate things. When you run git checkout -b feature-login, you create a branch that exists only on your machine. It has no connection to anything on the server yet.

The upstream branch (also called the tracking branch) is the remote branch your local branch is paired with. Once that pairing exists, Git knows two things automatically:

• git push sends your commits to that remote branch.
• git pull (and git status) compares your branch against it, so you see "ahead 2, behind 1" style summaries.

A freshly created branch has no pairing, so a bare git push has nowhere to go. That is the whole error. If you want the deeper mental model of how local branches relate to remotes, my guide to Git branching walks through it from scratch.

The fix: push with -u

Run the command Git suggested, or the shorter equivalent:

# long form, exactly as Git prints it
git push --set-upstream origin feature-login

# short form, identical behaviour
git push -u origin feature-login

-u is just the short alias for --set-upstream. Both create the remote branch feature-login on origin and set it as the upstream for your local branch in one step.

After this, you never need to repeat the long form on this branch:

# from now on, on feature-login, all of these work bare
git push
git pull
git status   # now shows ahead/behind counts

Always check what branch you are on first so you do not push the wrong one:

git branch --show-current

For a new feature branch, this first -u push is usually the step right before you work the branch into a pull request.

What the -u flag does, exactly

-u writes two lines into your local .git/config. For the example above:

[branch "feature-login"]
    remote = origin
    merge = refs/heads/feature-login

remote = origin says which remote this branch talks to. merge = refs/heads/feature-login says which branch on that remote it pairs with. That config is what lets bare git push and git pull resolve a target. You only need -u once per branch; the pairing persists.

You can confirm the pairing landed:

git branch -vv

The output shows each local branch with its tracking branch in square brackets, like feature-login abc1234 [origin/feature-login] add login form.

push -u vs a bare push

The difference is only on the first push of a new branch. After the upstream is set, they behave the same.

Make it automatic: push.autoSetupRemote

If you would rather never type -u again, Git can set the upstream for you on the first push of any new branch. This is the push.autoSetupRemote setting the error message mentions, added in Git 2.37 (released June 2022):

git config --global push.autoSetupRemote true

With that on, a bare git push on a brand-new branch will push it and set the upstream automatically, using a remote branch of the same name. It is the single best quality-of-life setting for anyone who creates a lot of branches. If you are on a Git older than 2.37, check your version with git --version; older releases do not have this option and you keep using -u by hand.

Why doesn't Git just do this by default?

Pushing a new branch is a deliberate act. Git defaults to making you name the remote and branch the first time so you do not accidentally publish a local experiment, or push to the wrong remote in a repo that has several. The error is the safety prompt; -u is you confirming "yes, send it to origin under this name." Once you have confirmed, Git stops asking.

Common variations and gotchas

A few things trip people up after they see this error:

• No remote at all. If git push -u origin feature-login answers with fatal: 'origin' does not appear to be a git repository, you have no remote named origin yet. Add one with git remote add origin <url>, then push; if you are wiring a local repo up to a remote for the first time, my walkthrough on how to add a remote to an existing repo covers the full sequence. If you instead see error: remote origin already exists, you have the opposite problem, which I cover in fixing 'remote origin already exists'.

• Pushing the default branch from a new repo. The same no-upstream message appears the first time you push main from a freshly initialised repo. The fix is identical: git push -u origin main. If that one fails with src refspec main does not match any instead, you have not committed anything yet; see the src refspec fix.

• Authentication failures after this step. Once the upstream is set, the push itself can still fail on credentials. If you are prompted for a password and rejected, GitHub no longer accepts account passwords over HTTPS, covered in the password authentication removed fix. For SSH remotes, a Permission denied (publickey) means your key is not registered, fixed by adding your SSH key to GitHub. If you keep hitting credential prompts, choosing between SSH and HTTPS remotes walks through which remote type avoids them.

FAQ

If this is one of the first Git errors you have hit, start from my Git for beginners guide, which links out to the whole error series. Closely related: when a push is rejected because the remote moved ahead of you, that is a different message covered in fixing 'failed to push some refs', and the git pull vs git fetch breakdown explains how your branch stays in sync once the upstream is wired up.