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 | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] 13 [--repo=<repository>] [-f | --force] [-v | --verbose] 14 [<repository> <refspec>...] 15 16DESCRIPTION 17----------- 18 19Updates remote refs using local refs, while sending objects 20necessary to complete the given refs. 21 22You can make interesting things happen to a repository 23every time you push into it, by setting up 'hooks' there. See 24documentation for linkgit:git-receive-pack[1]. 25 26 27OPTIONS 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+ 42The <src> side represents the source branch (or arbitrary 43"SHA1 expression", such as `master~4` (four parents before the 44tip of `master` branch); see linkgit:git-rev-parse[1]) that you 45want to push. The <dst> side represents the destination location. 46+ 47The local ref that matches <src> is used 48to fast forward the remote ref that matches <dst>. If 49the optional leading plus `+` is used, the remote ref is updated 50even 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+ 54A lonely <src> parameter (without a colon and a destination) pushes 55the <src> to the same name in the destination repository. 56+ 57Pushing an empty <src> allows you to delete the <dst> ref from 58the remote repository. 59+ 60The special refspec `:` (or `+:` to allow non-fast forward updates) 61directs git to push "matching" branches: for every branch that exists on 62the local side, the remote side is updated if a branch of the same name 63already exists on the remote side. This is the default operation mode 64if no explicit refspec is found (that is neither on the command line 65nor 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-------------------------- 114git push public #1 115git push --repo=public #2 116-------------------------- 117+ 118is that #1 always pushes to "public" whereas #2 pushes to "public" 119only if the current branch does not track a remote branch. This is 120useful 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 132include::urls-remotes.txt[] 133 134OUTPUT 135------ 136 137The output of "git push" depends on the transport method used; this 138section describes the output when pushing over the git protocol (either 139locally or via ssh). 140 141The status of the push is output in tabular form, with each line 142representing the status of a single ref. Each line is of the form: 143 144------------------------------- 145 <flag> <summary> <from> -> <to> (<reason>) 146------------------------------- 147 148flag:: 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 155summary:: 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 170from:: 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 175to:: 176 The name of the remote ref being updated, minus its 177 `refs/<type>/` prefix. 178 179reason:: 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 184Examples 185-------- 186 187git 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 194git push origin HEAD:: 195 A handy way to push the current branch to the same name on the 196 remote. 197 198git 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 204git 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 209git 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 216git 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 221Author 222------ 223Written by Junio C Hamano <gitster@pobox.com>, later rewritten in C 224by Linus Torvalds <torvalds@osdl.org> 225 226Documentation 227-------------- 228Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. 229 230GIT 231--- 232Part of the linkgit:git[1] suite