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