Remote Git Repositories | git push
The git push command
Pushing means writing a branch from the local repository to a remote repository. It is the opposite of git fetch: fetch imports branches into the local repository, while push exports branches to the remote repository. Because this command can overwrite changes incorrectly, use it carefully.
Usage
git push <remote> <branch>
Pushes the specified branch to <remote> together with all related commits and internal objects. This creates the local branch in the target repository. To prevent accidental overwrites, Git rejects the push if the receiving repository cannot integrate it as a fast-forward.
git push <remote> --force
Similar to the command above, but forces the push even when it is not a fast-forward. Do not use --force unless you fully understand what the push will do.
git push <remote> --all
Pushes all local branches to the specified remote repository.
git push <remote> --tags
Tags are not pushed automatically when pushing branches, even with --all. The --tags flag sends all local tags to the remote repository.
Additional notes
The most common use of git push is publishing local changes to a central repository. After making several local commits and reaching the point where you want to share them with other developers, you can clean them up with interactive rebase if needed, then push them to the central repository.
Git Tutorial: git push
The tutorial diagram shows what happens when local master has moved ahead of the central repository’s master, and you publish the changes with git push origin master. Remember that git push is essentially equivalent to running git merge master in the remote repository.
Force pushing
Git rejects a push when the result would require something other than a fast-forward merge. If the remote and local repositories have diverged, first fetch the remote branch, merge it into the local branch, and then try pushing again. This is similar to using svn update before committing changes in SVN.
The --force flag removes this restriction and makes the remote repository match the local repository. If changes were made in the remote repository after you last pulled, those changes are deleted. The only common case where a force push is needed is when you discover a defect in a recently published commit and fix it with git commit --amend or interactive rebase. Even then, before using --force, make sure no other developer has pulled the defective branch.
Push only to bare repositories
Pushing should be limited to repositories created with the --bare flag. Because pushing changes the structure of the remote repository, you should never push to another developer’s working repository. Bare repositories do not have a working directory, so pushing to them does not interfere with another developer’s work.
Example
The following example shows a common way to publish local work to the central repository. First, fetch the central repository’s master and rebase local changes on top of it to ensure local master is up to date. Before sharing commits, you may clean them up with interactive rebase. Then push all local master commits to the central repository.
git checkout master
git fetch origin master
git rebase -i origin/master
# Squash commits, fix up commit messages etc.
git push origin master
Because you have already confirmed that local master is up to date, the integration is a fast-forward and git push does not run into the non-fast-forward problem described above.