Skip to content

Pushing

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.

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).

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 wip-yourname

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

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
git push

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).

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

To push to a specific branch, say feature_x:

git push origin feature_x

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

Here, master is the branch name on the remote origin. You can use -u as a shorthand for --set-upstream.

To push to a repository that you haven’t made yet, or is empty:

  1. Create the repository on GitHub (if applicable)
  2. Copy the url given to you, in the form https://github.com/USERNAME/REPO_NAME.git
  3. Go to your local repository, and execute `git remote add origin URL`
    • To verify it was added, run git remote -v
  4. Run git push origin master

Your code should now be on GitHub

For more information view Adding a remote repository

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.

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

or

git push --force

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).
git push --tags

Pushes all of the git tags in the local repository that are not in the remote one.

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

git push

to update the remote repository.

  • git push [-f | —force][-v | —verbose] [ […]]
ParameterDetails
—forceOverwrites the remote ref to match your local ref. Can cause the remote repository to lose commits, so use with care.
—verboseRun verbosely.
The remote repository that is destination of the push operation.
Specify what remote ref to update with what local ref or object.

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.

(Source)