What pushing your changes means

Pushing means sending the commits you made on your computer up to GitHub's servers so other people can see them and work with them. When you push, you're uploading the specific changes you've saved locally — the new files, edits, and deletions — to a branch on the remote repository. GitHub then stores those changes and makes them visible to anyone with access to that repository.

Before you push, you need to have already committed your changes locally. A commit is a saved snapshot of your work with a message describing what you changed. Pushing takes those commits and moves them from your machine to GitHub.

Key Takeaways

  • You must commit your changes locally before you can push them — pushing sends commits that already exist on your computer to GitHub.
  • The basic command is git push origin branch-name, where branch-name is the name of the branch you're working on.
  • If you're pushing a new branch for the first time, you may need to use git push -u origin branch-name to set the upstream tracking.
  • GitHub will reject your push if someone else has already pushed changes to the same branch — you'll need to pull their changes first and resolve any conflicts.
  • After pushing, your changes appear on GitHub and are ready for review, merging, or collaboration with others.

The basic push command and what it does

Open your terminal or command prompt and navigate to your repository folder. Type git push origin branch-name, replacing branch-name with the actual name of the branch you're working on. For example, if you're on a branch called fix-login-bug, you would type git push origin fix-login-bug.

The word origin refers to the remote repository on GitHub — it's the default name Git gives to the server you cloned from. When you run this command, Git sends your commits to that remote location. If the push succeeds, you'll see a message confirming that your branch was updated on GitHub.

If you're pushing to the main branch (often called main or master), the command is the same: git push origin main. However, many teams require pull requests instead of pushing directly to main, so check your project's workflow first.

Pushing a branch for the first time

The first time you push a new branch, Git doesn't yet know which remote branch to track. You'll see an error message telling you to set the upstream branch. The easiest way is to use the -u flag: git push -u origin branch-name.

The -u flag sets up tracking, which means future pushes and pulls on that branch will automatically know to use the same remote branch. After you've run this command once with -u, you can use the simpler git push command on subsequent pushes without specifying the branch name.

Some Git interfaces and code editors will offer to set up tracking automatically when you try to push a new branch. If you see that option, you can click it instead of typing the command yourself.

What to do when GitHub rejects your push

If someone else has pushed changes to the same branch since you last pulled, GitHub will reject your push with a message saying the remote branch has diverged. This is a safety feature — it prevents you from accidentally overwriting someone else's work.

To fix this, run git pull origin branch-name to read their changes and merge them with yours. If the files they changed are different from the files you changed, the merge will happen automatically. If you both edited the same lines, Git will mark those sections as conflicts and ask you to decide which version to keep.

After you've resolved any conflicts (or if there were none), commit the merge and then push again. Your push will now succeed because your local branch includes the remote changes.

Understanding merge conflicts during a push

A merge conflict happens when you and someone else edited the same lines in the same file. When you pull before pushing, Git can't automatically decide which version is correct, so it stops and asks you to choose.

Open the conflicted file in your code editor. You'll see sections marked with <<<<<<<, =======, and >>>>>>>. The section between <<<<<<< and ======= is your version. The section between ======= and >>>>>>> is their version. Delete the markers and the version you don't want, keeping only the code that should be there.

After you've edited all conflicted files, stage them with git add ., commit with git commit -m "Merge branch...", and push again. The conflict is now resolved and your changes are on GitHub.

Pushing to a fork or a repository you don't own

If you've forked someone else's repository, origin points to your fork, not the original. When you push, your changes go to your fork on GitHub. To contribute back to the original repository, you'll need to create a pull request, which asks the original owner to review and merge your changes.

Push to your fork normally with git push origin branch-name. Then go to GitHub, navigate to your fork, and you'll see a button to create a pull request. This sends a notification to the original repository's owner with a link to your changes and a message explaining what you did.

If you want to keep your fork in sync with the original repository, you'll need to add the original as a second remote (usually called upstream) and pull from it periodically. This is a more advanced workflow, but it's common when contributing to open-source projects.

Checking what will be pushed before you push

Before you push, run git log origin/branch-name..HEAD to see a list of commits that exist on your computer but not yet on GitHub. This shows you exactly what will be sent when you push. Each line shows the commit message and hash, so you can verify you're pushing the right work.

You can also run git status to see if you have any uncommitted changes. If you do, they won't be pushed — only committed changes move to GitHub. Commit anything you want to include before pushing.

Frequently Asked Questions

What's the difference between git push and git push -u?

git push sends your commits to GitHub, but if it's a new branch, Git won't know which remote branch to track. git push -u does the same thing but also sets up tracking so future pushes on that branch happen automatically. Use -u the first time you push a new branch, then git push alone on future pushes.

Can I push if I haven't committed my changes?

No. Push only sends commits that already exist on your computer. If you have uncommitted changes, run git add . and git commit -m "your message" first. Then push. Uncommitted changes stay on your machine until you commit them.

What happens if I push to the wrong branch?

Your commits are now on that branch on GitHub. If you pushed to main by accident, contact your team lead or repository owner — they may be able to revert the commits. To prevent this, always check which branch you're on with git branch before pushing, especially to shared branches like main.

Do I need to push every commit I make?

No. You can make multiple commits locally and push them all at once. Push whenever you've finished a logical chunk of work or at the end of your day. Pushing more often is generally safer because it backs up your work to GitHub, but there's no requirement to push after every single commit.

Why does GitHub ask for my password when I push?

GitHub is verifying that you have permission to push to that repository. If you're using HTTPS, you'll need to enter your GitHub username and a personal access token (not your password). If you're using SSH, GitHub uses a key pair instead and won't ask for credentials. SSH is more convenient for frequent pushes.