Git: 'src refspec main does not match any' - How to Fix It

When Git says src refspec main does not match any, it means you asked it to push a branch called main, but there is no such branch to push. The message is identical whether your default branch is main or master (you will see src refspec master does not match any on older repos), and the same fix applies to both. Almost always the cause is that you have not made a single commit yet, so no branch actually exists, or you typed a branch name that does not match the one you are on (the classic main vs master mismatch). The fix: make a commit first, then push.

Here is the full error you are most likely staring at:

error: src refspec main does not match any
error: failed to push some refs to 'github.com:you/your-repo.git'

If your default branch is master, the first line reads error: src refspec master does not match any instead. Same problem, same fixes below.

The one-line fix

Nine times out of ten, you ran git init, added a remote, and went straight to git push without ever committing. A branch in Git does not exist until it points at a commit, so there is literally nothing named main to send. Commit, then push:

git add .
git commit -m "Initial commit"
git push -u origin main

If that succeeds, you are done. The rest of this page explains why it happened and covers the other causes, so you can recognise the error next time instead of guessing.

What "refspec" actually means

A refspec is just Git's word for "which reference am I pushing, and where does it go." In git push origin main, the main part is the source refspec: the local branch you want to send. When Git says it "does not match any," it is telling you that main does not resolve to anything on your side. The remote is fine; the problem is local. There is no commit, no branch, nothing for main to point at.

This is the whole reason a brand-new repo trips people up. You can git init and git remote add origin ... all you like, but until your first git commit, your repository has no branches at all.

Cause 1: you have not committed yet

This is the common case. Check what Git sees:

git status

If you get something like No commits yet and a list of untracked files, that confirms it. Staging files is not the same as committing them; the branch only comes into being on the commit. (If staging versus committing is fuzzy, I wrote a walkthrough of the Git staging area that clears it up.)

Stage and commit, then push:

git add .
git commit -m "Initial commit"
git push -u origin main

The -u sets main to track origin/main so future pushes are just git push. If you skip it, you may then hit a different message about no upstream branch, which is its own quick fix.

A gotcha worth flagging: if git commit itself fails with Please tell me who you are, the commit never happened, so the branch was never created, and your push will throw the refspec error. Set your identity first (I cover that in fixing the 'Please tell me who you are' error) and commit again.

Cause 2: you are on master, not main

Git versions from 2.28 (July 2020) onward let you configure the default branch name, and most people now use main. But older Git, and many existing repos, still default to master. If you committed on master and then ran git push origin main, Git correctly reports that main does not match any local branch.

Check which branch you are actually on:

git branch

The branch with the * next to it is your current branch. If it says master, you have two choices.

Push the branch you have:

git push -u origin master

Or rename your local branch to main, then push:

git branch -M main
git push -u origin main

git branch -M main renames the current branch to main (the -M forces it even if a branch by that name already exists). This is exactly the snippet GitHub shows you on a fresh empty repository, which is why pasting it on a repo with no commits still fails: rename does not create a branch out of nothing, so commit first.

If you want a clearer mental model of how branches come and go, Git branching explained for beginners is the cluster article for that.

Cause 3: a typo in the branch name

Less common but easy to miss. If your branch is feature/login and you type git push origin feature/loginn, same error. Git is matching the literal name. List your branches and copy the name exactly:

git branch
git push -u origin feature/login

Cause 4: detached HEAD, so no branch was created

If you checked out a commit, tag, or remote ref directly (for example git checkout <sha> or git checkout v1.0), you land in detached HEAD: you have commits, but HEAD is not on any branch, so git push origin main has no main to match. Confirm with:

git status

A detached HEAD reports HEAD detached at <sha>. Create a branch at your current position, then push it:

git switch -c main
git push -u origin main

git switch -c main makes a main branch pointing at the commit you are sitting on and moves HEAD onto it, so the refspec resolves.

Cause 5: pushing a tag or ref that does not exist

The same error appears when you push a tag or ref name that Git cannot resolve. git push origin v2.0 fails with src refspec v2.0 does not match any if no tag named v2.0 exists yet. Create the tag first, then push it:

git tag v2.0
git push origin v2.0

To push every local tag in one go, use git push origin --tags. The rule is the same as for branches: the name on the right of git push origin <name> has to resolve to something that actually exists locally.

How to tell which cause you have

A clean first-push sequence

If you are setting up a new repo from scratch and want to avoid this error entirely, this is the order that always works:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin git@github.com:you/your-repo.git
git push -u origin main

The key is that the commit comes before the push, and the branch name in the last line matches the one you renamed to. For the full walkthrough of setting up Git for a new project, including the remote and the first push end to end, that is the canonical guide. If instead you are wiring Git into a folder that already has files in it, see adding Git to an existing project for the right way to run git init over existing work. And if you are starting from a repo that already lives on GitHub, you would clone it rather than init, which I cover in starting work on an existing Git project.

Using SSH like the example above? If the push then complains about Permission denied (publickey), your key is not set up; see adding an SSH key to GitHub. On HTTPS remotes you may instead hit the password authentication removed error, which is a separate auth fix and not related to the refspec. If you are not sure which protocol to use in the first place, the difference between SSH and HTTPS remotes lays out the trade-offs.

Related push errors that look similar

The refspec error is specifically about the local side having nothing to send. Do not confuse it with failed to push some refs, which usually means the remote has commits you do not have locally and you need to pull first. That one is about the remote being ahead; this one is about your local branch not existing at all. Both end with the same failed to push some refs second line, so read the first line carefully: src refspec ... does not match any is the tell.

If you are new to all of this, the Git for beginners guide is the hub that ties the staging, branching, and pushing pieces together in order.

FAQ