After changing, staging, and committing code with Git, pushing is required to make your changes available to others and transfers your local changes to the repository server. This topic will cover how to properly push code using Git.
# Push a specific object to a remote branch
# General syntax
git push <remotename> <object>:<remotebranchname>
git push origin master:wip-yourname
Will push your master branch to the
wip-yourname branch of origin (most of the time, the repository you cloned from).
# Delete remote branch
Deleting the remote branch is the equivalent of pushing an empty object to it.
git push <remotename> :<remotebranchname>
git push origin :wip-yourname
Will delete the remote branch
Instead of using the colon, you can also use the --delete flag, which is better readable in some cases.
git push origin --delete wip-yourname
# Push a single commit
If you have a single commit in your branch that you want to push to a remote without pushing anything else, you can use the following
git push <remotename> <commit SHA>:<remotebranchname>
Assuming a git history like this
eeb32bc Commit 1 - already pushed 347d700 Commit 2 - want to push e539af8 Commit 3 - only local 5d339db Commit 4 - only local
to push only commit 347d700 to remote master use the following command
git push origin 347d700:master
will push your code to your existing upstream. Depending on the push configuration, it will either push code from you current branch (default in Git 2.x) or from all branches (default in Git 1.x).
# Specify remote repository
When working with git, it can be handy to have multiple remote repositories. To specify a remote repository to push to, just append its name to the command.
git push origin
# Specify Branch
To push to a specific branch, say
git push origin feature_x
# Set the remote tracking branch
Unless the branch you are working on originally comes from a remote repository, simply using
git push won't work the first time. You must perform the following command to tell git to push the current branch to a specific remote/branch combination
git push --set-upstream origin master
master is the branch name on the remote
origin. You can use
-u as a shorthand for
# Pushing to a new repository
To push to a repository that you haven't made yet, or is empty:
- Create the repository on GitHub (if applicable)
- Copy the url given to you, in the form
- Go to your local repository, and execute
git remote add origin URL
- To verify it was added, run
git remote -v
git push origin master
Your code should now be on GitHub
For more information view Adding a remote repository (opens new window)
Push code means that git will analyze the differences of your local commits and remote and send them to be written on the upstream. When push succeeds, your local repository and remote repository are synchronized and other users can see your commits.
For more details on the concepts of "upstream" and "downstream", see Remarks.
# Force Pushing
Sometimes, when you have local changes incompatible with remote changes (ie, when you cannot fast-forward the remote branch, or the remote branch is not a direct ancestor of your local branch), the only way to push your changes is a force push.
git push -f
git push --force
# Important notes
This will overwrite any remote changes and your remote will match your local.
Attention: Using this command may cause the remote repository to lose commits. Moreover, it is strongly advised against doing a force push if you are sharing this remote repository with others, since their history will retain every overwritten commit, thus rending their work out of sync with the remote repository.
As a rule of thumb, only force push when:
- Nobody except you pulled the changes you are trying to overwrite
- You can force everyone to clone a fresh copy after the forced push and make everyone apply their changes to it (people may hate you for this).
# Push tags
git push --tags
Pushes all of the
git tags in the local repository that are not in the remote one.
# Changing the default push behavior
Current updates the branch on the remote repository that shares a name with the current working branch.
git config push.default current
Simple pushes to the upstream branch, but will not work if the upstream branch is called something else.
git config push.default simple
Upstream pushes to the upstream branch, no matter what it is called.
git config push.default upstream
Matching pushes all branches that match on the local and the remote git config push.default upstream
After you've set the preferred style, use
to update the remote repository.
- git push [-f | --force][-v | --verbose] [
|--force||Overwrites the remote ref to match your local ref. Can cause the remote repository to lose commits, so use with care.|
|The remote repository that is destination of the push operation.|
|Specify what remote ref to update with what local ref or object.|
# Upstream & Downstream
In terms of source control, you're **"downstream"** when you copy (clone, checkout, etc) from a repository. Information flowed "downstream" to you.
When you make changes, you usually want to send them back **"upstream"** so they make it into that repository so that everyone pulling from the same source is working with all the same changes. This is mostly a social issue of how everyone can coordinate their work rather than a technical requirement of source control. You want to get your changes into the main project so you're not tracking divergent lines of development.
Sometimes you'll read about package or release managers (the people, not the tool) talking about submitting changes to "upstream". That usually means they had to adjust the original sources so they could create a package for their system. They don't want to keep making those changes, so if they send them "upstream" to the original source, they shouldn't have to deal with the same issue in the next release.