git-push – Update remote refs along with associated objects
[-u | –set-upstream]
[–no-verify] [<repository> [<refspec>…]]
up hooks there. See documentation for git-receive-pack(1).
branch.*.remote configuration for the current branch is consulted to determine where to push.
If the configuration is missing, it defaults to origin.
–mirror, –tags options, the command finds the default <refspec> by consulting remote.*.push
configuration, and if it is not found, honors push.default configuration to decide what to push
(See git-config(1) for the meaning of push.default).
is used, which corresponds to the simple value for push.default: the current branch is pushed
to the corresponding upstream branch, but as a safety measure, the push is aborted if the
upstream branch does not have the same name as the local one.
either a URL (see the section GIT URLS below) or the name of a remote (see the section
parameter is an optional plus +, followed by the source object <src>, followed by a colon
:, followed by the destination ref <dst>.
arbitrary “SHA-1 expression”, such as master~4 or HEAD (see gitrevisions(7)).
expressions cannot be used here, an actual ref must be named. If git push [<repository>]
without any <refspec> argument is set to update some ref at the destination with <src> with
remote.<repository>.push configuration variable, :<dst> part can be omitted—such a push
will update a ref that <src> normally updates without any <refspec> on the command line.
Otherwise, missing :<dst> means to update the same ref as the <src>.
default this is only allowed if <dst> is not a tag (annotated or lightweight), and then
only if it can fast-forward <dst>. By having the optional leading +, you can tell Git to
update the <dst> ref even if it is not allowed by default (e.g., it is not a fast-forward.)
This does not attempt to merge <src> into <dst>. See EXAMPLES below for details.
“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.
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.
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.
and sent to stdout instead of stderr. The full symbolic names of the refs will be given.
refs with a colon.
refs/tags that are missing from the remote but are pointing at commit-ish that are
reachable from the refs being pushed. This can also be specified with configuration
variable push.followTags. For more information, see push.followTags in git-config(1).
by the hooks and/or be logged. If false or –no-signed, no signing will be attempted. If
true or –signed, the push will fail if the server does not support signed pushes. If set
to if-asked, sign if and only if the server supports signed pushes. The push will also fail
if the actual call to gpg –sign fails. See git-receive-pack(1) for the details on the
on error, no refs are updated. If the server does not support atomic pushes the push will
remote repository over ssh, and you do not have the program in a directory on the default
used to overwrite it.
expected value. “git push” fails otherwise.
the “must fast-forward” rule in order to replace the history you originally published with
the rebased history. If somebody else built on top of your original history while you are
rebasing, the tip of the branch at the remote may advance with her commit, and blindly
pushing with –force will lose her work.
rebased and want to replace. If the remote ref still points at the commit you specified,
you can be sure that no other people did anything to the ref. It is like taking a “lease”
on the ref without explicitly locking it, and the remote ref is updated only if the “lease”
is still valid.
are going to be updated by requiring their current value to be the same as the
remote-tracking branch we have for them.
ref (alone), if it is going to be updated, by requiring its current value to be the same as
the remote-tracking branch we have for it.
be updated, by requiring its current value to be the same as the specified value <expect>
(which is allowed to be different from the remote-tracking branch we have for the refname,
or we do not even have to have such a remote-tracking branch when this form is used).
expected current value of the ref explicitly are still experimental and their semantics may
change as we gain experience with this feature.
ref used to overwrite it. Also, when –force-with-lease option is used, the command refuses
to update a remote ref whose current value does not match what is expected.
it with care.
set to matching or with multiple push destinations configured with remote.*.push may
overwrite refs other than the current branch (including local refs that are strictly behind
their remote counterpart). To force a push to only one branch, use a + in front of the
refspec to push (e.g git push origin +master to force a push to the master branch). See the
<refspec>… section above for details.
command-line argument takes precedence.
reference, used by argument-less git-pull(1) and other commands. For more information, see
branch.<name>.merge in git-config(1).
amount of sent data when the sender and receiver share many of the same objects in common.
The default is –thin.
Progress is not reported to the standard error stream.
a terminal, unless -q is specified. This flag forces progress status even if the standard
error stream is not directed to a terminal.
available on a remote-tracking branch. If check is used Git will verify that all submodule
commits that changed in the revisions to be pushed are available on at least one remote of
the submodule. If any commits are missing the push will be aborted and exit with non-zero
status. If on-demand is used all submodules that changed in the revisions to be pushed will
be pushed. If on-demand was not able to push all necessary revisions it will also be
aborted and exit with non-zero status. A value of no or using –no-recurse-submodules can
be used to override the push.recurseSubmodules configuration variable when no submodule
recursion is required.
chance to prevent the push. With –no-verify, the hook is bypassed completely.
server, and the path to the repository. Depending on the transport protocol, some of this
information may be absent.
fetching and rsync can be used for fetching and pushing, but these are inefficient and
deprecated; do not use them).
on unsecured networks.
differentiate a local path that contains a colon. For example the local path foo:bar could be
specified as an absolute path or ./foo:bar to avoid being misinterpreted as an ssh url.
option. See git-clone(1) for details.
remote-<transport> remote helper, if one exists. To explicitly request a remote helper, the
following syntax may be used:
the specific remote helper being invoked. See gitremote-helpers(1) for details.
different format for them (such that the URLs you use will be rewritten into URLs that work),
you can create a configuration section of the form:
insteadOf = work:
that takes a URL to be ”
git://example.org/path/to/repo.git” will be rewritten to
ssh://example.org/path/to/repo.git” for pushes, but pulls will still use the original URL.
a refspec which git will use by default.
Named remote in configuration file
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:
pushurl = <pushurl>
push = <refspec>
fetch = <refspec>
Named file in $GIT_DIR/remotes
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:
Push: and Pull: lines may be specified for additional branch mappings.
Named file in $GIT_DIR/branches
used to access the repository. This file should have the following format:
one on the command line. <branch> is the name of this file in $GIT_DIR/branches and <head>
defaults to master.
output when pushing over the Git protocol (either locally or via ssh).
single ref. Each line is of the form:
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).
you did not force the update.
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).
temporary error on the remote side, a break in the network connection, or other
deletion, the name of the local ref is omitted.
needed. For a failed ref, the reason for failure is described.
NOTE ABOUT FAST-FORWARDS
point at another commit B, it is called a fast-forward update if and only if B is a descendant
top of is a subset of the commits the new commit B builds on top of. Hence, it does not lose
else started at the same commit X, and you built a history leading to commit B while the other
person built a history leading to commit A. The history looks like this:
repository from which you two obtained the original commit X.
commit A. It is a fast-forward.
commit B. This does not fast-forward. If you did so, the changes introduced by commit A will be
lost, because everybody will now start building on top of B.
(history from X to A), you would need to first fetch the history from the repository, create a
history that contains changes done by both parties, and push the result back.
pull” will create a merge commit C between commits A and B.
–rebase”, and push the result back. The rebase will create a new commit D that builds the
change between X and B on top of A.
try to push, and it is possible even when you are pushing into a repository nobody else pushes
into. After you push commit A yourself (in the first picture in this section), replace it with
“git commit –amend” to produce commit B, and you try to push it out, because forgot that you
have pushed A out already. In such a case, and only if you are certain that nobody in the
meantime fetched your earlier commit A (and started building on top of it), you can run “git
push –force” to overwrite it. In other words, “git push –force” is a method reserved for a
case where you do mean to lose history.
no remote is configured for the current branch).
(remote.origin.merge configuration variable) if it has the same name as the current branch,
and errors out without pushing otherwise.
setting the push option of the remote, or the push.default configuration variable.
remote.origin.push HEAD. Any valid <refspec> (like the ones in the examples below) can be
configured as the default for git push origin.
description of “matching” branches.
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.
matches satellite/master (most probably refs/remotes/satellite/master) in the mothership
repository; do the same for dev and satellite/dev.
opposite direction in order to integrate the work done on satellite, and is often necessary
when you can only make connection in one way (i.e. satellite can ssh into mothership but
mothership cannot initiate connection to satellite because the latter is behind a firewall
or does not run sshd).
run git merge there to complete the emulation of git pull that were run on mothership to
pull changes made on satellite.
form is convenient to push the current branch without thinking about its local name.
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
refs/heads/experimental), and delete it.
updates. This can leave unreferenced commits dangling in the origin repository. Consider
the following situation, where a fast-forward is not possible:
unreachable. As such, these commits would be removed by a git gc command on the origin
Git 2.7.4 03/23/2016 GIT-PUSH(1)