1GIT-PUSH(1) Git Manual GIT-PUSH(1)
2
6 git-push - Update remote refs along with associated objects
7
9 git-push [--all] [--tags] [--receive-pack=<git-receive-pack>]
10 [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
11
13 Updates remote refs using local refs, while sending objects necessary
14 to complete the given refs.
15 You can make interesting things happen to a repository every time you
17 push into it, by setting up hooks there. See documentation for git-
18 receive-pack(1).
19
21 <repository>
22 The "remote" repository that is destination of a push operation.
23 See the section GIT URLS below.
24 <refspec>
26 The canonical format of a <refspec> parameter is ?<src>:<dst>; that
27 is, an optional plus , followed by the source ref, followed by a
28 colon :, followed by the destination ref.
29 The <src> side can be an arbitrary "SHA1 expression" that can be
31 used as an argument to git-cat-file -t. E.g. master~4 (push four
32 parents before the current master head).
33 The local ref that matches <src> is used to fast forward the remote
35 ref that matches <dst>. If the optional plus + is used, the remote
36 ref is updated even if it does not result in a fast forward update.
37 Note: If no explicit refspec is found, (that is neither on the
39 command line nor in any Push line of the corresponding remotes
40 file---see below), then all the heads that exist both on the local
41 side and on the remote side are updated.
42 tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>.
44 A parameter <ref> without a colon pushes the <ref> from the source
46 repository to the destination repository under the same name.
47 Pushing an empty <src> allows you to delete the <dst> ref from the
49 remote repository.
50 --all
52 Instead of naming each ref to push, specifies that all refs under
53 $GIT_DIR/refs/heads/ be pushed.
54 --tags
56 All refs under $GIT_DIR/refs/tags are pushed, in addition to
57 refspecs explicitly listed on the command line.
58 --receive-pack=<git-receive-pack>
60 Path to the git-receive-pack program on the remote end. Sometimes
61 useful when pushing to a remote repository over ssh, and you do not
62 have the program in a directory on the default $PATH.
63 --exec=<git-receive-pack>
65 Same as --receive-pack=<git-receive-pack>.
66 -f, --force
68 Usually, the command refuses to update a remote ref that is not an
69 ancestor of the local ref used to overwrite it. This flag disables
70 the check. This can cause the remote repository to lose commits;
71 use it with care.
72 --repo=<repo>
74 When no repository is specified the command defaults to "origin";
75 this overrides it.
76 --thin, --no-thin
78 These options are passed to git-send-pack. Thin transfer spends
79 extra cycles to minimize the number of objects to be sent and meant
80 to be used on slower connection.
81 -v
83 Run verbosely.
84
86 One of the following notations can be used to name the remote
87 repository:
88 · rsync://host.xz/path/to/repo.git/
91 · http://host.xz/path/to/repo.git/
93 · https://host.xz/path/to/repo.git/
95 · git://host.xz/path/to/repo.git/
97 · git://host.xz/~user/path/to/repo.git/
99 · ssh://[user@]host.xz[:port]/path/to/repo.git/
101 · ssh://[user@]host.xz/path/to/repo.git/
103 · ssh://[user@]host.xz/~user/path/to/repo.git/
105 · ssh://[user@]host.xz/~/path/to/repo.git
107 SSH is the default transport protocol over the network. You can
108 optionally specify which user to log-in as, and an alternate, scp-like
109 syntax is also supported. Both syntaxes support username expansion, as
110 does the native git protocol, but only the former supports port
111 specification. The following three are identical to the last three
112 above, respectively:
113 · [user@]host.xz:/path/to/repo.git/
116 · [user@]host.xz:~user/path/to/repo.git/
118 · [user@]host.xz:path/to/repo.git
120 To sync with a local directory, you can use:
121 · /path/to/repo.git/
124 · file:///path/to/repo.git/
126 They are mostly equivalent, except when cloning. See git-clone(1) for
127 details.
128
130 In addition to the above, as a short-hand, the name of a file in
131 $GIT_DIR/remotes directory can be given; the named file should be in
132 the following format:
133 URL: one of the above URL format
137 Push: <refspec>
138 Pull: <refspec>
139 Then such a short-hand is specified in place of <repository> without
142 <refspec> parameters on the command line, <refspec> specified on Push:
143 lines or Pull: lines are used for git-push and git-fetch/git-pull,
144 respectively. Multiple Push: and Pull: lines may be specified for
145 additional branch mappings.
146 Or, equivalently, in the $GIT_DIR/config (note the use of fetch instead
148 of Pull:):
149 [remote "<remote>"]
153 url = <url>
154 push = <refspec>
155 fetch = <refspec>
156 The name of a file in $GIT_DIR/branches directory can be specified as
159 an older notation short-hand; the named file should contain a single
160 line, a URL in one of the above formats, optionally followed by a hash
161 # and the name of remote head (URL fragment notation).
162 $GIT_DIR/branches/<remote> file that stores a <url> without the
163 fragment is equivalent to have this in the corresponding file in the
164 $GIT_DIR/remotes/ directory.
165 URL: <url>
169 Pull: refs/heads/master:<remote>
170 while having <url>#<head> is equivalent to
173 URL: <url>
177 Pull: refs/heads/<head>:<remote>
178
181 git push origin master
182 Find a ref that matches master in the source repository (most
183 likely, it would find refs/heads/master), and update the same ref
184 (e.g. refs/heads/master) in origin repository with it.
185 git push origin :experimental
187 Find a ref that matches experimental in the origin repository (e.g.
188 refs/heads/experimental), and delete it.
189 git push origin master:satellite/master
191 Find a ref that matches master in the source repository (most
192 likely, it would find refs/heads/master), and update the ref that
193 matches satellite/master (most likely, it would be
194 refs/remotes/satellite/master) in origin repository with it.
195 git push origin master:refs/heads/experimental
197 Create the branch experimental in the origin repository by copying
198 the current master branch. This form is usually needed to create a
199 new branch in the remote repository as there is no experimental
200 branch to match.
201
203 Written by Junio C Hamano <junkio@cox.net>, later rewritten in C by
204 Linus Torvalds <torvalds@osdl.org>
205
207 Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
208
210 Part of the git(7) suite
211Git 1.5.3.3 10/09/2007 GIT-PUSH(1)