You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
200 lines
6.8 KiB
200 lines
6.8 KiB
git-push(1) |
|
=========== |
|
|
|
NAME |
|
---- |
|
git-push - Update remote refs along with associated objects |
|
|
|
|
|
SYNOPSIS |
|
-------- |
|
[verse] |
|
'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] |
|
[--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...] |
|
|
|
DESCRIPTION |
|
----------- |
|
|
|
Updates 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 linkgit:git-receive-pack[1]. |
|
|
|
|
|
OPTIONS |
|
------- |
|
<repository>:: |
|
The "remote" repository that is destination of a push |
|
operation. See the section <<URLS,GIT URLS>> below. |
|
|
|
<refspec>:: |
|
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 represents the source branch (or arbitrary |
|
"SHA1 expression", such as `master~4` (four parents before the |
|
tip of `master` branch); see linkgit:git-rev-parse[1]) that you |
|
want to push. The <dst> side represents the destination location. |
|
+ |
|
The local ref that matches <src> is used |
|
to fast forward the remote ref that matches <dst> (or, if no <dst> was |
|
specified, the same ref that <src> referred to locally). If |
|
the optional leading 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 "matching" heads are |
|
pushed: for every head that exists on the local side, the remote side is |
|
updated if a head of the same name already exists on the remote side. |
|
+ |
|
`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. |
|
|
|
\--all:: |
|
Instead of naming each ref to push, specifies that all |
|
refs under `$GIT_DIR/refs/heads/` be pushed. |
|
|
|
\--mirror:: |
|
Instead of naming each ref to push, specifies that all |
|
refs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/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. |
|
|
|
\--dry-run:: |
|
Do everything except actually send the updates. |
|
|
|
\--tags:: |
|
All refs under `$GIT_DIR/refs/tags` are pushed, in |
|
addition to refspecs explicitly listed on the command |
|
line. |
|
|
|
\--receive-pack=<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. |
|
|
|
\--exec=<git-receive-pack>:: |
|
Same as \--receive-pack=<git-receive-pack>. |
|
|
|
-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=<repo>:: |
|
When no repository is specified the command defaults to |
|
"origin"; this overrides it. |
|
|
|
\--thin, \--no-thin:: |
|
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. |
|
|
|
-v, \--verbose:: |
|
Run verbosely. |
|
|
|
include::urls-remotes.txt[] |
|
|
|
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). |
|
|
|
The status of the push is output in tabular form, with each line |
|
representing the status of a single ref. Each line is of the form: |
|
|
|
------------------------------- |
|
<flag> <summary> <from> -> <to> (<reason>) |
|
------------------------------- |
|
|
|
flag:: |
|
A single character indicating the status of the ref. This is |
|
blank for a successfully pushed 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 (note that the status of up to |
|
date refs is shown only when `git push` is running verbosely). |
|
|
|
summary:: |
|
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 for the failure. |
|
The string `rejected` indicates that git did not try to send the |
|
ref at all (typically because it is not a fast forward). The |
|
string `remote rejected` indicates that the remote end refused |
|
the update; this rejection is typically caused by a hook on the |
|
remote side. The string `remote failure` indicates that 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). |
|
|
|
from:: |
|
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. |
|
|
|
Examples |
|
-------- |
|
|
|
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 :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 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. |
|
|
|
Author |
|
------ |
|
Written by Junio C Hamano <junkio@cox.net>, later rewritten in C |
|
by Linus Torvalds <torvalds@osdl.org> |
|
|
|
Documentation |
|
-------------- |
|
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. |
|
|
|
GIT |
|
--- |
|
Part of the linkgit:git[7] suite
|
|
|