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