Failed to push some refs
GitHub has commits your copy doesn’t, so git refused to overwrite them until you bring those changes in.
Also appears as
- To https://github.com/acme/my-app.git ! [rejected] main -> main (non-fast-forward) error: failed to push some refs to 'https://github.com/acme/my-app.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. If you want to integrate the remote changes, hint: use 'git pull' before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
- hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again.
Prompt to fix it
git push fails with "! [rejected] main -> main (fetch first)" and "failed to push some refs". Don’t force push. Fetch the remote and show me which commits are on the remote but not local, and the other way around. Then integrate them with git pull --rebase. If there are conflicts, resolve each one so both sides’ intended changes survive, and explain your choices. Run the build or tests before pushing again.
Paste into Layerwise or any AI coding tool.
What it means
Git only lets a push add commits on top of what the remote branch already has. fetch first means GitHub’s main has commits you don’t have locally. non-fast-forward means your copy already knows about them, but your branch doesn’t include them. Either way, pushing would erase work that only exists on GitHub, so git stops.
With AI tools, the other author is often you. Lovable, Bolt, v0, and GitHub’s web editor can commit straight to GitHub, so the remote moves while you also edit locally. A merged pull request or a teammate’s push does the same.
Unless you’ve set a pull preference, current git stops a plain git pull on diverged branches with fatal: Need to specify how to reconcile divergent branches. Run git pull --rebase: it replays your commits on top of GitHub’s and keeps history in a straight line. Avoid git push --force, which replaces GitHub’s branch with yours and deletes the commits you didn’t have.
Common causes
- An AI builder, GitHub’s web editor, or a merged pull request added commits to GitHub’s
mainwhile you worked locally. - You pushed from one computer, then committed on another without pulling first.
- The GitHub repository was created with a README or license, and your local project has its own first commit.
- Your local history was rewritten with
git commit --amendor a rebase after an earlier push.
How to fix it
- Run
git status, and commit or stash any unfinished changes. - Run
git pull --rebaseto put your commits on top of the ones on GitHub. This also works when GitHub started with its own README. - If git reports a conflict, fix the marked files, run
git addon them, thengit rebase --continue. - Run the app or tests to confirm the combined code works, then
git push.
Example fix
git status # commit or stash unfinished work first
git pull --rebase # put your commits on top of GitHub's
# Only if there are conflicts: fix the files, then
git add src/App.tsx
git rebase --continue
git pushRelated errors
All errorsCONFLICT (content): Merge conflict
Both versions changed the same lines in different ways, and git needs you to decide what the file should say before it finishes.
GH013: Push cannot contain secrets
GitHub found an API key or other secret in the commits you tried to push and blocked the whole push so the secret wouldn’t land in the repository.
fatal: not a git repository
Git searched this folder and every folder above it and found no repository, so the command has nothing to work on.
Build with an agent that checks its work
The Layerwise agent clicks through the live preview and reads the console, so it catches errors before you do.