Learning Objectives
By the end of this lesson you will be able to:
- Publish local commits to a remote with
git push - Explain what
-udoes and why you only need it once - Interpret the output Git prints after a successful push
- Diagnose the three failures that stop most first pushes
The First Push
Your repository is connected to origin. Your commits are still entirely local. One command sends them up:
git push -u origin main
Read it as four words: push (send commits), -u (remember this pairing), origin (to that remote), main (this branch).
Git responds:
Enumerating objects: 12, done.
Counting objects: 100% (12/12), done.
Writing objects: 100% (12/12), 1.42 KiB | 1.42 MiB/s, done.
To https://github.com/olena/qa-notes.git
* [new branch] main -> main
branch 'main' set up to track 'origin/main'.
The last two lines are the ones that matter. [new branch] main -> main means your branch now exists on the server. set up to track is what -u just did.
Refresh the repository page in your browser and your files are there — with the full commit history, every message you wrote, and your name on each one.
What -u Actually Does
-u (short for --set-upstream) creates a permanent link between your local main and the remote's main. From then on, Git knows where this branch belongs, and you can simply run:
git push
No remote, no branch name. Same for pulling. You need -u only on the very first push of a branch — after that, plain git push is correct forever.
That link also powers the helpful status lines you'll start seeing:
Your branch is ahead of 'origin/main' by 3 commits.
(use "git push" to publish your local commits)
Git is now tracking the gap between your machine and the server, and telling you about it every time you run git status.
The Daily Rhythm
Once set up, publishing work is three commands:
git add regression/payments-checklist.md
git commit -m "Add currency rounding cases to payments checklist"
git push
Stage, commit, push. Everything else in this trail was preparation for that loop.
Push often. A commit that lives only on your laptop is one spilled coffee away from not existing. Pushing at the end of each working session costs seconds and is the difference between "I lost a day" and "I lost nothing".
Three Failures and Their Fixes
1. "Updates were rejected because the remote contains work that you do not have locally"
The most common one, and it is not an error — it's Git protecting you. Someone else pushed while you were working, and accepting your push would leave their commits stranded.
Fix: get their work first, then push.
git pull
git push
The next lesson covers git pull properly. For now: pull, then push. Never reach for --force to make this message go away — force-pushing deletes other people's commits from the server, and it is one of the few genuinely destructive things Git will let you do.
2. "Authentication failed"
You're using an HTTPS URL and typing your account password. GitHub stopped accepting those in 2021. Generate a Personal Access Token in your account settings and use it as the password, or switch to SSH.
3. "src refspec main does not match any"
You're pushing a branch that doesn't exist locally. Two usual causes: you haven't made a single commit yet (there's nothing to push — commit first), or your branch is called master and you typed main. Check with:
git branch
and push whatever name it shows.
Pro Tip: Before your first push to a repository that might become public, run
git log --statand read the file list. Everything in that history — including files you deleted three commits ago — goes to the server. This is the last moment where checking is cheap.
Key Takeaways
git push -u origin mainpublishes your commits and links your local branch to the remote one- After the first push, plain
git pushis all you need for that branch - The stage → commit → push loop is the everyday rhythm of working with a team
- A rejected push means someone else pushed first: run
git pull, then push again — never--force - Authentication failures on HTTPS mean you need a Personal Access Token, not your password