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:: 96--force:: 97 Usually, the command refuses to update a remote ref that is 98 not an ancestor of the local ref used to overwrite it. 99 This flag disables the check. This can cause the 100 remote repository to lose commits; use it with care. 101 102--repo=<repo>:: 103 When no repository is specified the command defaults to 104 "origin"; this overrides it. 105 106--thin:: 107--no-thin:: 108 These options are passed to `git-send-pack`. Thin 109 transfer spends extra cycles to minimize the number of 110 objects to be sent and meant to be used on slower connection. 111 112-v:: 113--verbose:: 114 Run verbosely. 115 116include::urls-remotes.txt[] 117 118OUTPUT 119------ 120 121The output of "git push" depends on the transport method used; this 122section describes the output when pushing over the git protocol (either 123locally or via ssh). 124 125The status of the push is output in tabular form, with each line 126representing the status of a single ref. Each line is of the form: 127 128------------------------------- 129 <flag> <summary> <from> -> <to> (<reason>) 130------------------------------- 131 132flag:: 133 A single character indicating the status of the ref. This is 134 blank for a successfully pushed ref, `!` for a ref that was 135 rejected or failed to push, and '=' for a ref that was up to 136 date and did not need pushing (note that the status of up to 137 date refs is shown only when `git push` is running verbosely). 138 139summary:: 140 For a successfully pushed ref, the summary shows the old and new 141 values of the ref in a form suitable for using as an argument to 142 `git log` (this is `<old>..<new>` in most cases, and 143 `<old>...<new>` for forced non-fast forward updates). For a 144 failed update, more details are given for the failure. 145 The string `rejected` indicates that git did not try to send the 146 ref at all (typically because it is not a fast forward). The 147 string `remote rejected` indicates that the remote end refused 148 the update; this rejection is typically caused by a hook on the 149 remote side. The string `remote failure` indicates that the 150 remote end did not report the successful update of the ref 151 (perhaps because of a temporary error on the remote side, a 152 break in the network connection, or other transient error). 153 154from:: 155 The name of the local ref being pushed, minus its 156 `refs/<type>/` prefix. In the case of deletion, the 157 name of the local ref is omitted. 158 159to:: 160 The name of the remote ref being updated, minus its 161 `refs/<type>/` prefix. 162 163reason:: 164 A human-readable explanation. In the case of successfully pushed 165 refs, no explanation is needed. For a failed ref, the reason for 166 failure is described. 167 168Examples 169-------- 170 171git push origin master:: 172 Find a ref that matches `master` in the source repository 173 (most likely, it would find `refs/heads/master`), and update 174 the same ref (e.g. `refs/heads/master`) in `origin` repository 175 with it. If `master` did not exist remotely, it would be 176 created. 177 178git push origin :experimental:: 179 Find a ref that matches `experimental` in the `origin` repository 180 (e.g. `refs/heads/experimental`), and delete it. 181 182git push origin master:satellite/master:: 183 Find a ref that matches `master` in the source repository 184 (most likely, it would find `refs/heads/master`), and update 185 the ref that matches `satellite/master` (most likely, it would 186 be `refs/remotes/satellite/master`) in `origin` repository with it. 187 188git push origin master:refs/heads/experimental:: 189 Create the branch `experimental` in the `origin` repository 190 by copying the current `master` branch. This form is only 191 needed to create a new branch or tag in the remote repository when 192 the local name and the remote name are different; otherwise, 193 the ref name on its own will work. 194 195Author 196------ 197Written by Junio C Hamano <junkio@cox.net>, later rewritten in C 198by Linus Torvalds <torvalds@osdl.org> 199 200Documentation 201-------------- 202Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>. 203 204GIT 205--- 206Part of the linkgit:git[1] suite