table of contents
other versions
- wheezy 1:1.7.10.4-1+wheezy3
- wheezy-backports 1:1.9.1-1~bpo70+2
- jessie 1:2.1.4-2.1+deb8u2
- jessie-backports 1:2.11.0-3~bpo8+1
- testing 1:2.11.0-3
- unstable 1:2.11.0-4
- experimental 1:2.13.1+next.20170610-1
GIT-PUSH(1) | Git Manual | GIT-PUSH(1) |
NAME¶
git-push - Update remote refs along with associated objectsSYNOPSIS¶
git push [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream] [<repository> [<refspec>...]]
DESCRIPTION¶
Updates remote refs using local refs, while sending objects necessary to complete the given refs.OPTIONS¶
<repository>The "remote" repository that is
destination of a push operation. This parameter can be either a URL (see the
section GIT URLS below) or the name of a remote (see the section REMOTES
below).
<refspec>...
The format of a <refspec> parameter is
an optional plus +, followed by the source ref <src>, followed by a
colon :, followed by the destination ref <dst>. It is used to specify
with what <src> object the <dst> ref in the remote repository is
to be updated.
The <src> is often the name of the branch you would want to push, but it
can be any arbitrary "SHA-1 expression", such as master~4 or HEAD
(see gitrevisions(7)).
The <dst> tells which ref on the remote side is updated with this push.
Arbitrary expressions cannot be used here, an actual ref must be named. If
:<dst> is omitted, the same ref as <src> will be updated.
The object referenced by <src> is used to update the <dst> reference
on the remote side, but by default this is only allowed if the update can
fast-forward <dst>. By having the optional leading +, you can tell git
to update the <dst> ref even when the update is not a fast-forward. This
does not attempt to merge <src> into <dst>. See EXAMPLES
below for details.
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
Pushing an empty <src> allows you to delete the <dst> ref from the
remote repository.
The special refspec : (or +: to allow non-fast-forward updates) directs git to
push "matching" branches: for every branch that exists on the local
side, the remote side is updated if a branch of the same name already exists
on the remote side. This is the default operation mode 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).
--all
Instead of naming each ref to push, specifies
that all refs under refs/heads/ be pushed.
--prune
Remove remote branches that don’t have a
local counterpart. For example a remote branch tmp will be removed if a local
branch with the same name doesn’t exist any more. This also respects
refspecs, e.g. git push --prune remote refs/heads/*:refs/tmp/* would make sure
that remote refs/tmp/foo will be removed if refs/heads/foo doesn’t
exist.
--mirror
Instead of naming each ref to push, specifies
that all refs under refs/ (which includes but is not limited to refs/heads/,
refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly
created local refs will be pushed to the remote end, locally updated refs will
be force updated on the remote end, and deleted refs will be removed from the
remote end. This is the default if the configuration option
remote.<remote>.mirror is set.
-n, --dry-run
Do everything except actually send the
updates.
--porcelain
Produce machine-readable output. The output
status line for each ref will be tab-separated and sent to stdout instead of
stderr. The full symbolic names of the refs will be given.
--delete
All listed refs are deleted from the remote
repository. This is the same as prefixing all refs with a colon.
--tags
All refs under refs/tags are pushed, in
addition to refspecs explicitly listed on the command line.
--receive-pack=<git-receive-pack>, --exec=<git-receive-pack>
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.
-f, --force
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.
--repo=<repository>
This option is only relevant if no
<repository> argument is passed in the invocation. In this case, git
push derives the remote name from the current branch: If it tracks a
remote branch, then that remote repository is pushed to. Otherwise, the name
"origin" is used. For this latter case, this option can be used to
override the name "origin". In other words, the difference between
these two commands
is that #1 always pushes to "public" whereas #2 pushes to
"public" only if the current branch does not track a remote branch.
This is useful if you write an alias or script around git push.
-u, --set-upstream
git push public #1 git push --repo=public #2
For every branch that is up to date or
successfully pushed, add upstream (tracking) reference, used by argument-less
git-pull(1) and other commands. For more information, see
branch.<name>.merge in git-config(1).
--thin, --no-thin
These options are passed to
git-send-pack(1). A thin transfer significantly reduces the amount of
sent data when the sender and receiver share many of the same objects in
common. The default is --thin.
-q, --quiet
Suppress all output, including the listing of
updated refs, unless an error occurs. Progress is not reported to the standard
error stream.
-v, --verbose
Run verbosely.
--progress
Progress status is reported on the standard
error stream by default when it is attached to a terminal, unless -q is
specified. This flag forces progress status even if the standard error stream
is not directed to a terminal.
--recurse-submodules=check
Check whether all submodule commits used by
the revisions to be pushed are available on a remote tracking branch.
Otherwise the push will be aborted and the command will exit with non-zero
status.
GIT URLS¶
In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.•ssh://[user@]host.xz[:port]/path/to/repo.git/
•git://host.xz[:port]/path/to/repo.git/
•http[s]://host.xz[:port]/path/to/repo.git/
•ftp[s]://host.xz[:port]/path/to/repo.git/
•rsync://host.xz/path/to/repo.git/
•[user@]host.xz:path/to/repo.git/
•ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
•git://host.xz[:port]/~[user]/path/to/repo.git/
•[user@]host.xz:/~[user]/path/to/repo.git/
•/path/to/repo.git/
•<transport>::<address>
[url "<actual url base>"] insteadOf = <other url base>
[url "git://git.host.xz/"] insteadOf = host.xz:/path/to/ insteadOf = work:
[url "<actual url base>"] pushInsteadOf = <other url base>
[url "ssh://example.org/"] pushInsteadOf = git://example.org/
REMOTES¶
The name of one of the following can be used instead of a URL as <repository> argument:•a remote in the git configuration file:
$GIT_DIR/config,
•a file in the $GIT_DIR/remotes
directory, or
•a file in the $GIT_DIR/branches
directory.
Named remote in configuration file¶
You can choose to provide the name of a remote which you had previously configured using git-remote(1), git-config(1) or even by a manual edit to the $GIT_DIR/config file. The URL of this remote will be used to access the repository. The refspec of this remote will be used by default when you do not provide a refspec on the command line. The entry in the config file would appear like this:[remote "<name>"] url = <url> pushurl = <pushurl> push = <refspec> fetch = <refspec>
Named file in $GIT_DIR/remotes¶
You can choose to provide the name of a file in $GIT_DIR/remotes. The URL in this file will be used to access the repository. The refspec in this file will be used as default when you do not provide a refspec on the command line. This file should have the following format:URL: one of the above URL format Push: <refspec> Pull: <refspec>
Named file in $GIT_DIR/branches¶
You can choose to provide the name of a file in $GIT_DIR/branches. The URL in this file will be used to access the repository. This file should have the following format:<url>#<head>
refs/heads/<head>:refs/heads/<branch>
HEAD:refs/heads/<head>
OUTPUT¶
The output of "git push" depends on the transport method used; this section describes the output when pushing over the git protocol (either locally or via ssh).<flag> <summary> <from> -> <to> (<reason>)
<flag> \t <from>:<to> \t <summary> (<reason>)
A single character indicating the status of
the ref:
(space)
summary
for a successfully pushed fast-forward;
+
for a successful forced update;
-
for a successfully deleted ref;
*
for a successfully pushed new ref;
!
for a ref that was rejected or failed to push;
and
=
for a ref that was up to date and did not need
pushing.
For a successfully pushed ref, the summary
shows the old and new values of the ref in a form suitable for using as an
argument to git log (this is <old>..<new> in most cases, and
<old>...<new> for forced non-fast-forward updates).
For a failed update, more details are given:
rejected
from
Git did not try to send the ref at all,
typically because it is not a fast-forward and you did not force the
update.
remote rejected
The remote end refused the update. Usually
caused by a hook on the remote side, or because the remote repository has one
of the following safety options in effect: receive.denyCurrentBranch (for
pushes to the checked out branch), receive.denyNonFastForwards (for forced
non-fast-forward updates), receive.denyDeletes or receive.denyDeleteCurrent.
See git-config(1).
remote failure
The remote end did not report the successful
update of the ref, perhaps because of a temporary error on the remote side, a
break in the network connection, or other transient error.
The name of the local ref being pushed, minus
its refs/<type>/ prefix. In the case of deletion, the name of the local
ref is omitted.
to
The name of the remote ref being updated,
minus its refs/<type>/ prefix.
reason
A human-readable explanation. In the case of
successfully pushed refs, no explanation is needed. For a failed ref, the
reason for failure is described.
NOTE ABOUT FAST-FORWARDS¶
When an update changes a branch (or more in general, a ref) that used to point at commit A to point at another commit B, it is called a fast-forward update if and only if B is a descendant of A.B / ---X---A
B---C / / ---X---A
B D / / ---X---A
EXAMPLES¶
git pushWorks like git push <remote>, where
<remote> is the current branch’s remote (or origin, if no remote
is configured for the current branch).
git push origin
Without additional configuration, works like
git push origin :.
The default behavior of this command when no <refspec> is given can be
configured by setting the push option of the remote.
For example, to default to pushing only the current branch to origin use git
config remote.origin.push HEAD. Any valid <refspec> (like the ones in
the examples below) can be configured as the default for git push
origin.
git push origin :
Push "matching" branches to origin.
See <refspec> in the OPTIONS section above for a description of
"matching" branches.
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. If master did not
exist remotely, it would be created.
git push origin HEAD
A handy way to push the current branch to the
same name on the remote.
git push origin master:satellite/master dev:satellite/dev
Use the source ref that matches master (e.g.
refs/heads/master) to update the ref that matches satellite/master (most
probably refs/remotes/satellite/master) in the origin repository, then do the
same for dev and satellite/dev.
git push origin HEAD:master
Push the current branch to the remote ref
matching master in the origin repository. This form is convenient to push the
current branch without thinking about its local name.
git push origin master:refs/heads/experimental
Create the branch experimental in the origin
repository by copying the current master branch. This form is only needed to
create a new branch or tag in the remote repository when the local name and
the remote name are different; otherwise, the ref name on its own will
work.
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 +dev:master
Update the origin repository’s master
branch with the dev branch, allowing non-fast-forward updates. This can
leave unreferenced commits dangling in the origin repository. Consider the
following situation, where a fast-forward is not possible:
The above command would change the origin repository to
Commits A and B would no longer belong to a branch with a symbolic name, and so
would be unreachable. As such, these commits would be removed by a git gc
command on the origin repository.
o---o---o---A---B origin/master \ X---Y---Z dev
A---B (unnamed branch) / o---o---o---X---Y---Z master
GIT¶
Part of the git(1) suite03/19/2016 | Git 1.7.10.4 |