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