1GIT-CLONE(1)                      Git Manual                      GIT-CLONE(1)
2
3
4

NAME

6       git-clone - Clone a repository into a new directory
7

SYNOPSIS

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                 [--dissociate] [--separate-git-dir <git dir>]
13                 [--depth <depth>] [--[no-]single-branch] [--no-tags]
14                 [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
15                 [--jobs <n>] [--] <repository> [<directory>]
16
17

DESCRIPTION

19       Clones a repository into a newly created directory, creates
20       remote-tracking branches for each branch in the cloned repository
21       (visible using git branch -r), and creates and checks out an initial
22       branch that is forked from the cloned repository’s currently active
23       branch.
24
25       After the clone, a plain git fetch without arguments will update all
26       the remote-tracking branches, and a git pull without arguments will in
27       addition merge the remote master branch into the current master branch,
28       if any (this is untrue when "--single-branch" is given; see below).
29
30       This default configuration is achieved by creating references to the
31       remote branch heads under refs/remotes/origin and by initializing
32       remote.origin.url and remote.origin.fetch configuration variables.
33

OPTIONS

35       --local, -l
36           When the repository to clone from is on a local machine, this flag
37           bypasses the normal "Git aware" transport mechanism and clones the
38           repository by making a copy of HEAD and everything under objects
39           and refs directories. The files under .git/objects/ directory are
40           hardlinked to save space when possible.
41
42           If the repository is specified as a local path (e.g.,
43           /path/to/repo), this is the default, and --local is essentially a
44           no-op. If the repository is specified as a URL, then this flag is
45           ignored (and we never use the local optimizations). Specifying
46           --no-local will override the default when /path/to/repo is given,
47           using the regular Git transport instead.
48
49       --no-hardlinks
50           Force the cloning process from a repository on a local filesystem
51           to copy the files under the .git/objects directory instead of using
52           hardlinks. This may be desirable if you are trying to make a
53           back-up of your repository.
54
55       --shared, -s
56           When the repository to clone is on the local machine, instead of
57           using hard links, automatically setup .git/objects/info/alternates
58           to share the objects with the source repository. The resulting
59           repository starts out without any object of its own.
60
61           NOTE: this is a possibly dangerous operation; do not use it unless
62           you understand what it does. If you clone your repository using
63           this option and then delete branches (or use any other Git command
64           that makes any existing commit unreferenced) in the source
65           repository, some objects may become unreferenced (or dangling).
66           These objects may be removed by normal Git operations (such as git
67           commit) which automatically call git gc --auto. (See git-gc(1).) If
68           these objects are removed and were referenced by the cloned
69           repository, then the cloned repository will become corrupt.
70
71           Note that running git repack without the -l option in a repository
72           cloned with -s will copy objects from the source repository into a
73           pack in the cloned repository, removing the disk space savings of
74           clone -s. It is safe, however, to run git gc, which uses the -l
75           option by default.
76
77           If you want to break the dependency of a repository cloned with -s
78           on its source repository, you can simply run git repack -a to copy
79           all objects from the source repository into a pack in the cloned
80           repository.
81
82       --reference[-if-able] <repository>
83           If the reference repository is on the local machine, automatically
84           setup .git/objects/info/alternates to obtain objects from the
85           reference repository. Using an already existing repository as an
86           alternate will require fewer objects to be copied from the
87           repository being cloned, reducing network and local storage costs.
88           When using the --reference-if-able, a non existing directory is
89           skipped with a warning instead of aborting the clone.
90
91           NOTE: see the NOTE for the --shared option, and also the
92           --dissociate option.
93
94       --dissociate
95           Borrow the objects from reference repositories specified with the
96           --reference options only to reduce network transfer, and stop
97           borrowing from them after a clone is made by making necessary local
98           copies of borrowed objects. This option can also be used when
99           cloning locally from a repository that already borrows objects from
100           another repository—the new repository will borrow objects from the
101           same repository, and this option can be used to stop the borrowing.
102
103       --quiet, -q
104           Operate quietly. Progress is not reported to the standard error
105           stream.
106
107       --verbose, -v
108           Run verbosely. Does not affect the reporting of progress status to
109           the standard error stream.
110
111       --progress
112           Progress status is reported on the standard error stream by default
113           when it is attached to a terminal, unless -q is specified. This
114           flag forces progress status even if the standard error stream is
115           not directed to a terminal.
116
117       --no-checkout, -n
118           No checkout of HEAD is performed after the clone is complete.
119
120       --bare
121           Make a bare Git repository. That is, instead of creating
122           <directory> and placing the administrative files in
123           <directory>/.git, make the <directory> itself the $GIT_DIR. This
124           obviously implies the -n because there is nowhere to check out the
125           working tree. Also the branch heads at the remote are copied
126           directly to corresponding local branch heads, without mapping them
127           to refs/remotes/origin/. When this option is used, neither
128           remote-tracking branches nor the related configuration variables
129           are created.
130
131       --mirror
132           Set up a mirror of the source repository. This implies --bare.
133           Compared to --bare, --mirror not only maps local branches of the
134           source to local branches of the target, it maps all refs (including
135           remote-tracking branches, notes etc.) and sets up a refspec
136           configuration such that all these refs are overwritten by a git
137           remote update in the target repository.
138
139       --origin <name>, -o <name>
140           Instead of using the remote name origin to keep track of the
141           upstream repository, use <name>.
142
143       --branch <name>, -b <name>
144           Instead of pointing the newly created HEAD to the branch pointed to
145           by the cloned repository’s HEAD, point to <name> branch instead. In
146           a non-bare repository, this is the branch that will be checked out.
147           --branch can also take tags and detaches the HEAD at that commit in
148           the resulting repository.
149
150       --upload-pack <upload-pack>, -u <upload-pack>
151           When given, and the repository to clone from is accessed via ssh,
152           this specifies a non-default path for the command run on the other
153           end.
154
155       --template=<template_directory>
156           Specify the directory from which templates will be used; (See the
157           "TEMPLATE DIRECTORY" section of git-init(1).)
158
159       --config <key>=<value>, -c <key>=<value>
160           Set a configuration variable in the newly-created repository; this
161           takes effect immediately after the repository is initialized, but
162           before the remote history is fetched or any files checked out. The
163           key is in the same format as expected by git-config(1) (e.g.,
164           core.eol=true). If multiple values are given for the same key, each
165           value will be written to the config file. This makes it safe, for
166           example, to add additional fetch refspecs to the origin remote.
167
168       --depth <depth>
169           Create a shallow clone with a history truncated to the specified
170           number of commits. Implies --single-branch unless
171           --no-single-branch is given to fetch the histories near the tips of
172           all branches. If you want to clone submodules shallowly, also pass
173           --shallow-submodules.
174
175       --shallow-since=<date>
176           Create a shallow clone with a history after the specified time.
177
178       --shallow-exclude=<revision>
179           Create a shallow clone with a history, excluding commits reachable
180           from a specified remote branch or tag. This option can be specified
181           multiple times.
182
183       --[no-]single-branch
184           Clone only the history leading to the tip of a single branch,
185           either specified by the --branch option or the primary branch
186           remote’s HEAD points at. Further fetches into the resulting
187           repository will only update the remote-tracking branch for the
188           branch this option was used for the initial cloning. If the HEAD at
189           the remote did not point at any branch when --single-branch clone
190           was made, no remote-tracking branch is created.
191
192       --no-tags
193           Don’t clone any tags, and set remote.<remote>.tagOpt=--no-tags in
194           the config, ensuring that future git pull and git fetch operations
195           won’t follow any tags. Subsequent explicit tag fetches will still
196           work, (see git-fetch(1)).
197
198           Can be used in conjunction with --single-branch to clone and
199           maintain a branch with no references other than a single cloned
200           branch. This is useful e.g. to maintain minimal clones of the
201           default branch of some repository for search indexing.
202
203       --recurse-submodules[=<pathspec]
204           After the clone is created, initialize and clone submodules within
205           based on the provided pathspec. If no pathspec is provided, all
206           submodules are initialized and cloned. This option can be given
207           multiple times for pathspecs consisting of multiple entries. The
208           resulting clone has submodule.active set to the provided pathspec,
209           or "." (meaning all submodules) if no pathspec is provided.
210
211           Submodules are initialized and cloned using their default settings.
212           This is equivalent to running git submodule update --init
213           --recursive <pathspec> immediately after the clone is finished.
214           This option is ignored if the cloned repository does not have a
215           worktree/checkout (i.e. if any of --no-checkout/-n, --bare, or
216           --mirror is given)
217
218       --[no-]shallow-submodules
219           All submodules which are cloned will be shallow with a depth of 1.
220
221       --separate-git-dir=<git dir>
222           Instead of placing the cloned repository where it is supposed to
223           be, place the cloned repository at the specified directory, then
224           make a filesystem-agnostic Git symbolic link to there. The result
225           is Git repository can be separated from working tree.
226
227       -j <n>, --jobs <n>
228           The number of submodules fetched at the same time. Defaults to the
229           submodule.fetchJobs option.
230
231       <repository>
232           The (possibly remote) repository to clone from. See the GIT URLS
233           section below for more information on specifying repositories.
234
235       <directory>
236           The name of a new directory to clone into. The "humanish" part of
237           the source repository is used if no directory is explicitly given
238           (repo for /path/to/repo.git and foo for host.xz:foo/.git). Cloning
239           into an existing directory is only allowed if the directory is
240           empty.
241

GIT URLS

243       In general, URLs contain information about the transport protocol, the
244       address of the remote server, and the path to the repository. Depending
245       on the transport protocol, some of this information may be absent.
246
247       Git supports ssh, git, http, and https protocols (in addition, ftp, and
248       ftps can be used for fetching, but this is inefficient and deprecated;
249       do not use it).
250
251       The native transport (i.e. git:// URL) does no authentication and
252       should be used with caution on unsecured networks.
253
254       The following syntaxes may be used with them:
255
256       ·   ssh://[user@]host.xz[:port]/path/to/repo.git/
257
258       ·   git://host.xz[:port]/path/to/repo.git/
259
260       ·   http[s]://host.xz[:port]/path/to/repo.git/
261
262       ·   ftp[s]://host.xz[:port]/path/to/repo.git/
263
264       An alternative scp-like syntax may also be used with the ssh protocol:
265
266       ·   [user@]host.xz:path/to/repo.git/
267
268       This syntax is only recognized if there are no slashes before the first
269       colon. This helps differentiate a local path that contains a colon. For
270       example the local path foo:bar could be specified as an absolute path
271       or ./foo:bar to avoid being misinterpreted as an ssh url.
272
273       The ssh and git protocols additionally support ~username expansion:
274
275       ·   ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
276
277       ·   git://host.xz[:port]/~[user]/path/to/repo.git/
278
279       ·   [user@]host.xz:/~[user]/path/to/repo.git/
280
281       For local repositories, also supported by Git natively, the following
282       syntaxes may be used:
283
284       ·   /path/to/repo.git/
285
286       ·   file:///path/to/repo.git/
287
288       These two syntaxes are mostly equivalent, except the former implies
289       --local option.
290
291       When Git doesn’t know how to handle a certain transport protocol, it
292       attempts to use the remote-<transport> remote helper, if one exists. To
293       explicitly request a remote helper, the following syntax may be used:
294
295       ·   <transport>::<address>
296
297       where <address> may be a path, a server and path, or an arbitrary
298       URL-like string recognized by the specific remote helper being invoked.
299       See gitremote-helpers(1) for details.
300
301       If there are a large number of similarly-named remote repositories and
302       you want to use a different format for them (such that the URLs you use
303       will be rewritten into URLs that work), you can create a configuration
304       section of the form:
305
306                   [url "<actual url base>"]
307                           insteadOf = <other url base>
308
309
310       For example, with this:
311
312                   [url "git://git.host.xz/"]
313                           insteadOf = host.xz:/path/to/
314                           insteadOf = work:
315
316
317       a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
318       rewritten in any context that takes a URL to be
319       "git://git.host.xz/repo.git".
320
321       If you want to rewrite URLs for push only, you can create a
322       configuration section of the form:
323
324                   [url "<actual url base>"]
325                           pushInsteadOf = <other url base>
326
327
328       For example, with this:
329
330                   [url "ssh://example.org/"]
331                           pushInsteadOf = git://example.org/
332
333
334       a URL like "git://example.org/path/to/repo.git" will be rewritten to
335       "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
336       use the original URL.
337

EXAMPLES

339       ·   Clone from upstream:
340
341               $ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
342               $ cd my-linux
343               $ make
344
345
346       ·   Make a local clone that borrows from the current directory, without
347           checking things out:
348
349               $ git clone -l -s -n . ../copy
350               $ cd ../copy
351               $ git show-branch
352
353
354       ·   Clone from upstream while borrowing from an existing local
355           directory:
356
357               $ git clone --reference /git/linux.git \
358                       git://git.kernel.org/pub/scm/.../linux.git \
359                       my-linux
360               $ cd my-linux
361
362
363       ·   Create a bare repository to publish your changes to the public:
364
365               $ git clone --bare -l /home/proj/.git /pub/scm/proj.git
366
367

GIT

369       Part of the git(1) suite
370
371
372
373Git 2.18.1                        05/14/2019                      GIT-CLONE(1)
Impressum