What pushing your changes means

Pushing means sending the commits you made on your computer to GitHub's servers. Until you push, your changes exist only on your machine. Once pushed, they live on GitHub where others can see them, pull them down, and build on your work.

The push command uploads your commits to a branch — usually main or a feature branch you created. GitHub then stores those commits permanently and updates the repository everyone else sees.

Key Takeaways

  • You must commit your changes locally before you can push them; pushing sends commits that already exist on your computer.
  • The basic command is git push origin branch-name, where branch-name is the branch you want to send to GitHub.
  • If you created a new branch locally, you may need to set the upstream branch the first time you push using git push -u origin branch-name.
  • GitHub will reject a push if your local branch is behind the remote version; you must pull and merge changes first.
  • After pushing, you can open a pull request on GitHub to ask others to review your changes before merging to main.

The basic push command and what it does

Open your terminal or command prompt in your project folder and type:

git push origin branch-name

Replace branch-name with the actual name of the branch you want to push — for example, git push origin main or git push origin fix-login-bug. The word origin refers to your GitHub repository; it is the default name Git assigns to the remote location you cloned from.

Git will then upload all commits on your local branch that do not yet exist on GitHub. If the push succeeds, you will see a message confirming the branch was updated on the remote.

Setting the upstream branch on your first push

If you created a new branch locally and are pushing it to GitHub for the first time, use this command instead:

git push -u origin branch-name

The -u flag tells Git to set the upstream branch. This means Git will remember that your local branch is linked to that specific branch on GitHub. After the first push, you can use the shorter git push command without typing the branch name again.

Without setting upstream, you would have to type the full command every time. Setting it once saves repetition and reduces mistakes.

What to do when GitHub rejects your push

Sometimes you will see an error message like "rejected" or "failed to push some refs". This usually means your local branch is out of sync with the remote version — someone else pushed changes to that branch while you were working, or you pulled changes but have not merged them yet.

To fix this, pull the latest changes first:

git pull origin branch-name

Git will merge the remote changes into your local branch. If there are conflicts — places where both you and someone else changed the same lines — Git will mark them and ask you to resolve them manually. After resolving conflicts and committing the merge, try pushing again.

If you are working on a feature branch that only you use, a rejected push is rare. It happens most often on shared branches like main.

Pushing to main versus pushing to a feature branch

Many teams do not allow direct pushes to main. Instead, you push to a separate feature branch, then open a pull request on GitHub asking others to review your changes. A team member approves the pull request, and then the changes are merged into main.

If your repository requires pull requests, you will not be able to push directly to main — GitHub will reject the push. In that case, create a new branch, push to it, and then use GitHub's web interface to open a pull request.

To create and push a new branch in one workflow:

git checkout -b my-feature-branch git push -u origin my-feature-branch

Then go to GitHub.com, find your repository, and you will see a prompt to open a pull request for the branch you just pushed.

Checking what will be pushed before you push

Before pushing, you can see what commits are on your local branch but not yet on GitHub. Type:

git log origin/branch-name..HEAD

This shows all commits that exist locally but have not been pushed. It is a useful safety check if you want to confirm you are pushing the right work.

You can also check the status of your branch relative to the remote:

git status

This will tell you if your branch is ahead of the remote and by how many commits.

Common mistakes and how to avoid them

The most common mistake is forgetting to commit before pushing. If you have made changes but have not committed them, git push will not send anything — it only pushes commits that already exist. Always run git status first to see what is staged and what is not.

Another mistake is pushing to the wrong branch. Double-check which branch you are on by running git branch — the branch with an asterisk is your current branch. If you are on the wrong branch, switch first with git checkout branch-name, then push.

A third mistake is pushing without pulling first when working on a shared branch. If someone else pushed changes while you were working, your push will be rejected. Always pull before pushing on branches others use.

Frequently Asked Questions

What is the difference between git push and git pull?

Push sends your commits to GitHub. Pull downloads commits from GitHub to your computer. You pull to get others' work; you push to share your own work.

Can I undo a push after I have already sent it to GitHub?

Yes, but it is complicated and affects others if they have already pulled your commits. The safest way is to create a new commit that reverses the changes, then push that. Ask your team lead before undoing a push on a shared branch.

Do I have to push every commit I make?

No. You can make many commits locally before pushing once. Push whenever you want to back up your work or share it with others. There is no rule about how often to push.

What does "origin" mean in git push origin?

Origin is the default name for the remote repository — the GitHub location you cloned from. When you cloned the repository, Git automatically set up origin to point to that GitHub URL.

Why does GitHub ask me to set up SSH or HTTPS before I can push?

GitHub needs to know it is really you before accepting your pushes. You set up either SSH keys or a personal access token so GitHub can authenticate you. Your first push may prompt you to complete this setup if you have not already.