Documentation/git-push.txt

   1 git-push(1)
   2 ===========
   3
   4 NAME
   5 ----
   6 git-push - Update remote refs along with associated objects
   7
   8
   9 SYNOPSIS
  10 --------
  11 [verse]
  12 'git push' [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
  13            [--repo=<repository>] [-f | --force] [-v | --verbose]
  14            [<repository> <refspec>...]
  15
  16 DESCRIPTION
  17 -----------
  18
  19 Updates remote refs using local refs, while sending objects
  20 necessary to complete the given refs.
  21
  22 You can make interesting things happen to a repository
  23 every time you push into it, by setting up 'hooks' there.  See
  24 documentation for linkgit:git-receive-pack[1].
  25
  26
  27 OPTIONS
  28 -------
  29 <repository>::
  30         The "remote" repository that is destination of a push
  31         operation.  This parameter can be either a URL
  32         (see the section <<URLS,GIT URLS>> below) or the name
  33         of a remote (see the section <<REMOTES,REMOTES>> below).
  34
  35 <refspec>...::
  36         The format of a <refspec> parameter is an optional plus
  37         `{plus}`, followed by the source ref <src>, followed
  38         by a colon `:`, followed by the destination ref <dst>.
  39         It is used to specify with what <src> object the <dst> ref
  40         in the remote repository is to be updated.
  41 +
  42 The <src> side represents the source branch (or arbitrary
  43 "SHA1 expression", such as `master~4` (four parents before the
  44 tip of `master` branch); see linkgit:git-rev-parse[1]) that you
  45 want to push.  The <dst> side represents the destination location.
  46 +
  47 The local ref that matches <src> is used
  48 to fast forward the remote ref that matches <dst>.  If
  49 the optional leading plus `+` is used, the remote ref is updated
  50 even if it does not result in a fast forward update.
  51 +
  52 `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
  53 +
  54 A lonely <src> parameter (without a colon and a destination) pushes
  55 the <src> to the same name in the destination repository.
  56 +
  57 Pushing an empty <src> allows you to delete the <dst> ref from
  58 the remote repository.
  59 +
  60 The special refspec `:` (or `+:` to allow non-fast forward updates)
  61 directs git to push "matching" branches: for every branch that exists on
  62 the local side, the remote side is updated if a branch of the same name
  63 already exists on the remote side.  This is the default operation mode
  64 if no explicit refspec is found (that is neither on the command line
  65 nor in any Push line of the corresponding remotes file---see below).
  66
  67 --all::
  68         Instead of naming each ref to push, specifies that all
  69         refs under `$GIT_DIR/refs/heads/` be pushed.
  70
  71 --mirror::
  72         Instead of naming each ref to push, specifies that all
  73         refs under `$GIT_DIR/refs/` (which includes but is not
  74         limited to `refs/heads/`, `refs/remotes/`, and `refs/tags/`)
  75         be mirrored to the remote repository.  Newly created local
  76         refs will be pushed to the remote end, locally updated refs
  77         will be force updated on the remote end, and deleted refs
  78         will be removed from the remote end.  This is the default
  79         if the configuration option `remote.<remote>.mirror` is
  80         set.
  81
  82 --dry-run::
  83         Do everything except actually send the updates.
  84
  85 --tags::
  86         All refs under `$GIT_DIR/refs/tags` are pushed, in
  87         addition to refspecs explicitly listed on the command
  88         line.
  89
  90 --receive-pack=<git-receive-pack>::
  91 --exec=<git-receive-pack>::
  92         Path to the 'git-receive-pack' program on the remote
  93         end.  Sometimes useful when pushing to a remote
  94         repository over ssh, and you do not have the program in
  95         a directory on the default $PATH.
  96
  97 -f::
  98 --force::
  99         Usually, the command refuses to update a remote ref that is
 100         not an ancestor of the local ref used to overwrite it.
 101         This flag disables the check.  This can cause the
 102         remote repository to lose commits; use it with care.
 103
 104 --repo=<repository>::
 105         This option is only relevant if no <repository> argument is
 106         passed in the invocation. In this case, 'git-push' derives the
 107         remote name from the current branch: If it tracks a remote
 108         branch, then that remote repository is pushed to. Otherwise,
 109         the name "origin" is used. For this latter case, this option
 110         can be used to override the name "origin". In other words,
 111         the difference between these two commands
 112 +
 113 --------------------------
 114 git push public         #1
 115 git push --repo=public  #2
 116 --------------------------
 117 +
 118 is that #1 always pushes to "public" whereas #2 pushes to "public"
 119 only if the current branch does not track a remote branch. This is
 120 useful if you write an alias or script around 'git-push'.
 121
 122 --thin::
 123 --no-thin::
 124         These options are passed to 'git-send-pack'.  Thin
 125         transfer spends extra cycles to minimize the number of
 126         objects to be sent and meant to be used on slower connection.
 127
 128 -v::
 129 --verbose::
 130         Run verbosely.
 131
 132 include::urls-remotes.txt[]
 133
 134 OUTPUT
 135 ------
 136
 137 The output of "git push" depends on the transport method used; this
 138 section describes the output when pushing over the git protocol (either
 139 locally or via ssh).
 140
 141 The status of the push is output in tabular form, with each line
 142 representing the status of a single ref. Each line is of the form:
 143
 144 -------------------------------
 145  <flag> <summary> <from> -> <to> (<reason>)
 146 -------------------------------
 147
 148 flag::
 149         A single character indicating the status of the ref. This is
 150         blank for a successfully pushed ref, `!` for a ref that was
 151         rejected or failed to push, and '=' for a ref that was up to
 152         date and did not need pushing (note that the status of up to
 153         date refs is shown only when `git push` is running verbosely).
 154
 155 summary::
 156         For a successfully pushed ref, the summary shows the old and new
 157         values of the ref in a form suitable for using as an argument to
 158         `git log` (this is `<old>..<new>` in most cases, and
 159         `<old>...<new>` for forced non-fast forward updates). For a
 160         failed update, more details are given for the failure.
 161         The string `rejected` indicates that git did not try to send the
 162         ref at all (typically because it is not a fast forward). The
 163         string `remote rejected` indicates that the remote end refused
 164         the update; this rejection is typically caused by a hook on the
 165         remote side. The string `remote failure` indicates that the
 166         remote end did not report the successful update of the ref
 167         (perhaps because of a temporary error on the remote side, a
 168         break in the network connection, or other transient error).
 169
 170 from::
 171         The name of the local ref being pushed, minus its
 172         `refs/<type>/` prefix. In the case of deletion, the
 173         name of the local ref is omitted.
 174
 175 to::
 176         The name of the remote ref being updated, minus its
 177         `refs/<type>/` prefix.
 178
 179 reason::
 180         A human-readable explanation. In the case of successfully pushed
 181         refs, no explanation is needed. For a failed ref, the reason for
 182         failure is described.
 183
 184 Examples
 185 --------
 186
 187 git push origin master::
 188         Find a ref that matches `master` in the source repository
 189         (most likely, it would find `refs/heads/master`), and update
 190         the same ref (e.g. `refs/heads/master`) in `origin` repository
 191         with it.  If `master` did not exist remotely, it would be
 192         created.
 193
 194 git push origin HEAD::
 195         A handy way to push the current branch to the same name on the
 196         remote.
 197
 198 git push origin master:satellite/master dev:satellite/dev::
 199         Use the source ref that matches `master` (e.g. `refs/heads/master`)
 200         to update the ref that matches `satellite/master` (most probably
 201         `refs/remotes/satellite/master`) in the `origin` repository, then
 202         do the same for `dev` and `satellite/dev`.
 203
 204 git push origin HEAD:master::
 205         Push the current branch to the remote ref matching `master` in the
 206         `origin` repository. This form is convenient to push the current
 207         branch without thinking about its local name.
 208
 209 git push origin master:refs/heads/experimental::
 210         Create the branch `experimental` in the `origin` repository
 211         by copying the current `master` branch.  This form is only
 212         needed to create a new branch or tag in the remote repository when
 213         the local name and the remote name are different; otherwise,
 214         the ref name on its own will work.
 215
 216 git push origin :experimental::
 217         Find a ref that matches `experimental` in the `origin` repository
 218         (e.g. `refs/heads/experimental`), and delete it.
 219
 220
 221 Author
 222 ------
 223 Written by Junio C Hamano <gitster@pobox.com>, later rewritten in C
 224 by Linus Torvalds <torvalds@osdl.org>
 225
 226 Documentation
 227 --------------
 228 Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
 229
 230 GIT
 231 ---
 232 Part of the linkgit:git[1] suite