GIT\-PUSHSection: Git Manual (1)
Index Return to Main Contents
NAMEgit-push - Update remote refs along with associated objects
git-push [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
DESCRIPTIONUpdates remote refs using local refs, while sending objects necessary to complete the given refs.
You can make interesting things happen to a repository every time you push into it, by setting up hooks there. See documentation for git-receive-pack(1).
- The "remote" repository that is destination of a push operation. See the section GIT URLS below.
The canonical format of a <refspec> parameter is ?<src>:<dst>; that is, an optional plus , followed by the source ref, followed by a colon :, followed by the destination ref.
The <src> side can be an arbitrary "SHA1 expression" that can be used as an argument to git-cat-file -t. E.g. master~4 (push four parents before the current master head).
The local ref that matches <src> is used to fast forward the remote ref that matches <dst>. If the optional plus + is used, the remote ref is updated even if it does not result in a fast forward update.
Note: If no explicit refspec is found, (that is neither on the command line nor in any Push line of the corresponding remotes file---see below), then all the heads that exist both on the local side and on the remote side are updated.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
A parameter <ref> without a colon pushes the <ref> from the source repository to the destination repository under the same name.
Pushing an empty <src> allows you to delete the <dst> ref from the remote repository.
- Instead of naming each ref to push, specifies that all refs under $GIT_DIR/refs/heads/ be pushed.
- All refs under $GIT_DIR/refs/tags are pushed, in addition to refspecs explicitly listed on the command line.
- Path to the git-receive-pack program on the remote end. Sometimes useful when pushing to a remote repository over ssh, and you do not have the program in a directory on the default $PATH.
- Same as --receive-pack=<git-receive-pack>.
- Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it. This flag disables the check. This can cause the remote repository to lose commits; use it with care.
- When no repository is specified the command defaults to "origin"; this overrides it.
- These options are passed to git-send-pack. Thin transfer spends extra cycles to minimize the number of objects to be sent and meant to be used on slower connection.
- Run verbosely.
GIT URLSOne of the following notations can be used to name the remote repository:
REMOTESIn addition to the above, as a short-hand, the name of a file in $GIT_DIR/remotes directory can be given; the named file should be in the following format:
.ft C URL: one of the above URL format Push: <refspec> Pull: <refspec> .ft
Or, equivalently, in the $GIT_DIR/config (note the use of fetch instead of Pull:):
.ft C [remote "<remote>"] url = <url> push = <refspec> fetch = <refspec> .ft
.ft C URL: <url> Pull: refs/heads/master:<remote> .ft
.ft C URL: <url> Pull: refs/heads/<head>:<remote> .ft
git push origin master
- Find a ref that matches master in the source repository (most likely, it would find refs/heads/master), and update the same ref (e.g. refs/heads/master) in origin repository with it.
git push origin :experimental
- Find a ref that matches experimental in the origin repository (e.g. refs/heads/experimental), and delete it.
git push origin master:satellite/master
- Find a ref that matches master in the source repository (most likely, it would find refs/heads/master), and update the ref that matches satellite/master (most likely, it would be refs/remotes/satellite/master) in origin repository with it.
git push origin master:refs/heads/experimental
- Create the branch experimental in the origin repository by copying the current master branch. This form is usually needed to create a new branch in the remote repository as there is no experimental branch to match.
AUTHORWritten by Junio C Hamano <email@example.com>, later rewritten in C by Linus Torvalds <firstname.lastname@example.org>
DOCUMENTATIONDocumentation by Junio C Hamano and the git-list <email@example.com>.
GITPart of the git(7) suite