1GIT-CLONE(1) Git Manual GIT-CLONE(1)
2
6 git-clone - Clone a repository into a new directory
7
9 git clone [--template=<template_directory>]
10 [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
11 [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
12 [--depth <depth>] [--recursive] [--] <repository> [<directory>]
13
16 Clones a repository into a newly created directory, creates
17 remote-tracking branches for each branch in the cloned repository
18 (visible using git branch -r), and creates and checks out an initial
19 branch that is forked from the cloned repository’s currently active
20 branch.
21 After the clone, a plain git fetch without arguments will update all
23 the remote-tracking branches, and a git pull without arguments will in
24 addition merge the remote master branch into the current master branch,
25 if any.
26 This default configuration is achieved by creating references to the
28 remote branch heads under refs/remotes/origin and by initializing
29 remote.origin.url and remote.origin.fetch configuration variables.
30
32 --local, -l
33 When the repository to clone from is on a local machine, this flag
34 bypasses the normal "git aware" transport mechanism and clones the
35 repository by making a copy of HEAD and everything under objects
36 and refs directories. The files under .git/objects/ directory are
37 hardlinked to save space when possible. This is now the default
38 when the source repository is specified with /path/to/repo syntax,
39 so it essentially is a no-op option. To force copying instead of
40 hardlinking (which may be desirable if you are trying to make a
41 back-up of your repository), but still avoid the usual "git aware"
42 transport mechanism, --no-hardlinks can be used.
43 --no-hardlinks
45 Optimize the cloning process from a repository on a local
46 filesystem by copying files under .git/objects directory.
47 --shared, -s
49 When the repository to clone is on the local machine, instead of
50 using hard links, automatically setup .git/objects/info/alternates
51 to share the objects with the source repository. The resulting
52 repository starts out without any object of its own.
53 NOTE: this is a possibly dangerous operation; do not use it unless
55 you understand what it does. If you clone your repository using
56 this option and then delete branches (or use any other git command
57 that makes any existing commit unreferenced) in the source
58 repository, some objects may become unreferenced (or dangling).
59 These objects may be removed by normal git operations (such as git
60 commit) which automatically call git gc --auto. (See git-gc(1).) If
61 these objects are removed and were referenced by the cloned
62 repository, then the cloned repository will become corrupt.
63 Note that running git repack without the -l option in a repository
65 cloned with -s will copy objects from the source repository into a
66 pack in the cloned repository, removing the disk space savings of
67 clone -s. It is safe, however, to run git gc, which uses the -l
68 option by default.
69 If you want to break the dependency of a repository cloned with -s
71 on its source repository, you can simply run git repack -a to copy
72 all objects from the source repository into a pack in the cloned
73 repository.
74 --reference <repository>
76 If the reference repository is on the local machine, automatically
77 setup .git/objects/info/alternates to obtain objects from the
78 reference repository. Using an already existing repository as an
79 alternate will require fewer objects to be copied from the
80 repository being cloned, reducing network and local storage costs.
81 NOTE: see the NOTE for the --shared option.
83 --quiet, -q
85 Operate quietly. Progress is not reported to the standard error
86 stream. This flag is also passed to the ‘rsync’ command when given.
87 --verbose, -v
89 Run verbosely. Does not affect the reporting of progress status to
90 the standard error stream.
91 --progress
93 Progress status is reported on the standard error stream by default
94 when it is attached to a terminal, unless -q is specified. This
95 flag forces progress status even if the standard error stream is
96 not directed to a terminal.
97 --no-checkout, -n
99 No checkout of HEAD is performed after the clone is complete.
100 --bare
102 Make a bare GIT repository. That is, instead of creating
103 <directory> and placing the administrative files in
104 <directory>/.git, make the <directory> itself the $GIT_DIR. This
105 obviously implies the -n because there is nowhere to check out the
106 working tree. Also the branch heads at the remote are copied
107 directly to corresponding local branch heads, without mapping them
108 to refs/remotes/origin/. When this option is used, neither
109 remote-tracking branches nor the related configuration variables
110 are created.
111 --mirror
113 Set up a mirror of the remote repository. This implies --bare.
114 --origin <name>, -o <name>
116 Instead of using the remote name origin to keep track of the
117 upstream repository, use <name>.
118 --branch <name>, -b <name>
120 Instead of pointing the newly created HEAD to the branch pointed to
121 by the cloned repository’s HEAD, point to <name> branch instead. In
122 a non-bare repository, this is the branch that will be checked out.
123 --upload-pack <upload-pack>, -u <upload-pack>
125 When given, and the repository to clone from is accessed via ssh,
126 this specifies a non-default path for the command run on the other
127 end.
128 --template=<template_directory>
130 Specify the directory from which templates will be used; (See the
131 "TEMPLATE DIRECTORY" section of git-init(1).)
132 --depth <depth>
134 Create a shallow clone with a history truncated to the specified
135 number of revisions. A shallow repository has a number of
136 limitations (you cannot clone or fetch from it, nor push from nor
137 into it), but is adequate if you are only interested in the recent
138 history of a large project with a long history, and would want to
139 send in fixes as patches.
140 --recursive
142 After the clone is created, initialize all submodules within, using
143 their default settings. This is equivalent to running git submodule
144 update --init --recursive immediately after the clone is finished.
145 This option is ignored if the cloned repository does not have a
146 worktree/checkout (i.e. if any of --no-checkout/-n, --bare, or
147 --mirror is given)
148 <repository>
150 The (possibly remote) repository to clone from. See the URLS
151 section below for more information on specifying repositories.
152 <directory>
154 The name of a new directory to clone into. The "humanish" part of
155 the source repository is used if no directory is explicitly given
156 (repo for /path/to/repo.git and foo for host.xz:foo/.git). Cloning
157 into an existing directory is only allowed if the directory is
158 empty.
159
161 In general, URLs contain information about the transport protocol, the
162 address of the remote server, and the path to the repository. Depending
163 on the transport protocol, some of this information may be absent.
164 Git natively supports ssh, git, http, https, ftp, ftps, and rsync
166 protocols. The following syntaxes may be used with them:
167 · ssh://[user@]host.xz[:port]/path/to/repo.git/
169 · git://host.xz[:port]/path/to/repo.git/
171 · http[s]://host.xz[:port]/path/to/repo.git/
173 · ftp[s]://host.xz[:port]/path/to/repo.git/
175 · rsync://host.xz/path/to/repo.git/
177 An alternative scp-like syntax may also be used with the ssh protocol:
179 · [user@]host.xz:path/to/repo.git/
181 The ssh and git protocols additionally support ~username expansion:
183 · ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
185 · git://host.xz[:port]/~[user]/path/to/repo.git/
187 · [user@]host.xz:/~[user]/path/to/repo.git/
189 For local respositories, also supported by git natively, the following
191 syntaxes may be used:
192 · /path/to/repo.git/
194 · file:///path/to/repo.git/
196 These two syntaxes are mostly equivalent, except the former implies
198 --local option.
199 When git doesn’t know how to handle a certain transport protocol, it
201 attempts to use the remote-<transport> remote helper, if one exists. To
202 explicitly request a remote helper, the following syntax may be used:
203 · <transport>::<address>
205 where <address> may be a path, a server and path, or an arbitrary
207 URL-like string recognized by the specific remote helper being invoked.
208 See git-remote-helpers(1) for details.
209 If there are a large number of similarly-named remote repositories and
211 you want to use a different format for them (such that the URLs you use
212 will be rewritten into URLs that work), you can create a configuration
213 section of the form:
214 [url "<actual url base>"]
216 insteadOf = <other url base>
217 For example, with this:
220 [url "git://git.host.xz/"]
222 insteadOf = host.xz:/path/to/
223 insteadOf = work:
224 a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
227 rewritten in any context that takes a URL to be
228 "git://git.host.xz/repo.git".
229 If you want to rewrite URLs for push only, you can create a
231 configuration section of the form:
232 [url "<actual url base>"]
234 pushInsteadOf = <other url base>
235 For example, with this:
238 [url "ssh://example.org/"]
240 pushInsteadOf = git://example.org/
241 a URL like "git://example.org/path/to/repo.git" will be rewritten to
244 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
245 use the original URL.
246
248 · Clone from upstream:
249 $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
251 $ cd my2.6
252 $ make
253 · Make a local clone that borrows from the current directory, without
256 checking things out:
257 $ git clone -l -s -n . ../copy
259 $ cd ../copy
260 $ git show-branch
261 · Clone from upstream while borrowing from an existing local
264 directory:
265 $ git clone --reference my2.6 \
267 git://git.kernel.org/pub/scm/.../linux-2.7 \
268 my2.7
269 $ cd my2.7
270 · Create a bare repository to publish your changes to the public:
273 $ git clone --bare -l /home/proj/.git /pub/scm/proj.git
275 · Create a repository on the kernel.org machine that borrows from
278 Linus:
279 $ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \
281 /pub/scm/.../me/subsys-2.6.git
282
285 Written by Linus Torvalds <torvalds@osdl.org[1]>
286
288 Documentation by Junio C Hamano and the git-list
289 <git@vger.kernel.org[2]>.
290
292 Part of the git(1) suite
293
295 1. torvalds@osdl.org
296 mailto:torvalds@osdl.org
297 2. git@vger.kernel.org
299 mailto:git@vger.kernel.org
300Git 1.7.1 08/16/2017 GIT-CLONE(1)