简体中文 ▾ 主题 ▾ 最新版本 ▾ git-clone 最后更新于 2.52.0

名称

git-clone - 将仓库克隆到一个新目录

概要

git clone [--template=<template-directory>]
	  [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
	  [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
	  [--dissociate] [--separate-git-dir <git-dir>]
	  [--depth <depth>] [--[no-]single-branch] [--[no-]tags]
	  [--recurse-submodules[=<pathspec>]] [--[no-]shallow-submodules]
	  [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow]
	  [--filter=<filter-spec> [--also-filter-submodules]] [--] <repository>
	  [<directory>]

描述

将仓库克隆到一个新创建的目录，为克隆仓库中的每个分支创建远程跟踪分支（可以使用 git branch --remotes 查看），并创建一个从克隆仓库当前活动分支分叉出来的初始分支并检出。

克隆完成后，不带参数的普通 git fetch 将会更新所有远程跟踪分支，而不带参数的 git pull 将会在此基础上合并远程 master 分支到当前 master 分支（如果存在）。（当给出 --single-branch 时此描述不成立；见下文）。

此默认配置是通过在 refs/remotes/origin 下创建指向远程分支头的引用，并通过初始化 remote.origin.url 和 remote.origin.fetch 配置变量来实现的。

选项

-l
--local

当要克隆的仓库在本地机器上时，此标志会绕过正常的“Git 感知”传输机制，并通过复制 HEAD 以及 objects 和 refs 目录下的所有内容来克隆仓库。 .git/objects/ 目录下的文件在可能的情况下会被硬链接以节省空间。

如果仓库被指定为本地路径（例如 /path/to/repo），则此为默认设置，并且 --local 实际上是一个 no-op（无操作）。如果仓库被指定为 URL，则此标志将被忽略（我们从不使用本地优化）。指定 --no-local 将在给出 /path/to/repo 时覆盖默认设置，转而使用常规的 Git 传输。

如果仓库的 $GIT_DIR/objects 包含符号链接或本身就是一个符号链接，则克隆将失败。这是一个安全措施，用于通过解引用符号链接来防止无意中复制文件。

出于安全原因，此选项不适用于其他用户拥有的仓库，并且必须指定 --no-local 才能成功克隆。

注意：此操作可能与源仓库的并发修改发生竞争，类似于在修改 <src> 时运行 cp -r <src> <dst>。

--no-hardlinks

强制从本地文件系统上的仓库克隆过程复制 .git/objects 目录下的文件，而不是使用硬链接。当您尝试备份仓库时，这可能是可取的。

-s
--shared

当要克隆的仓库在本地机器上时，而不是使用硬链接，自动设置 .git/objects/info/alternates 来与源仓库共享对象。结果仓库最初不包含任何自己的对象。

注意：这是一个可能存在危险的操作；除非您了解其作用，否则请不要使用它。如果您使用此选项克隆了您的仓库，然后删除了源仓库中的分支（或使用了任何其他使现有提交不再被引用的 Git 命令），则某些对象可能会变为未被引用（或悬空）。这些对象可能会被常规的 Git 操作（如 git commit，它会自动调用 git maintenance run --auto）移除。（参见 git-maintenance[1]。）如果这些对象被移除并且曾被克隆仓库引用，那么克隆仓库将损坏。

请注意，在用 --shared 克隆的仓库中运行不带 --local 选项的 git repack 会将对象从源仓库复制到克隆仓库的一个 pack 中，从而消除 clone --shared 的磁盘空间节省。然而，运行默认使用 --local 选项的 git gc 是安全的。

如果您想打破用 --shared 克隆的仓库与其源仓库的依赖关系，您可以简单地运行 git repack -a 将所有对象从源仓库复制到克隆仓库的一个 pack 中。

--reference[-if-able] <repository>

如果引用 <repository> 在本地机器上，自动设置 .git/objects/info/alternates 以从引用 <repository> 获取对象。使用已存在的仓库作为备用仓库将需要从要克隆的仓库复制更少对象，从而降低网络和本地存储成本。使用 --reference-if-able 时，不存在的目录将被跳过并发出警告，而不是中止克隆。

注意：参见 --shared 选项的 NOTE，以及 --dissociate 选项。

--dissociate

仅为了减少网络传输，从指定的引用仓库借用对象，并在克隆完成后通过创建必要的本地副本停止借用。当从一个已经借用其他仓库对象的仓库进行本地克隆时，也可以使用此选项——新仓库将从同一个仓库借用对象，然后可以使用此选项停止借用。

-q
--quiet

安静运行。不向标准错误流报告进度。

-v
--verbose

详细运行。不影响向标准错误流报告进度状态。

--progress

当标准错误流连接到终端时，进度状态默认会在标准错误流上报告，除非指定了 --quiet。此标志强制显示进度状态，即使标准错误流未连接到终端。

--server-option=<option>

在使用协议版本 2 进行通信时，将给定字符串传输到服务器。给定字符串不得包含 NUL 或 LF 字符。服务器处理服务器选项（包括未知的选项）是服务器特定的。当给出多个 --server-option=<option> 时，它们将按命令行上的顺序全部发送给对方。当命令行上未给出 --server-option=<option> 时，将使用配置变量 remote.<name>.serverOption 的值。

-n
--no-checkout

克隆完成后不执行 HEAD 的检出。

--[no-]reject-shallow

如果源仓库是浅层仓库，则失败。 clone.rejectShallow 配置变量可用于指定默认值。

--bare

创建一个裸 Git 仓库。也就是说，不创建<directory>并在<directory>/.git 中放置管理文件，而是让<directory>本身成为 $GIT_DIR。这显然意味着 --no-checkout，因为没有地方可以检出工作树。同时，远程的本地分支头直接复制到相应的本地分支头，而不映射到 refs/remotes/origin/。使用此选项时，不会创建远程跟踪分支或相关的配置变量。

--sparse

采用稀疏检出，最初只在顶层目录中存在文件。 git-sparse-checkout[1] 命令可用于按需扩展工作目录。

--filter=<filter-spec>

使用部分克隆功能，并请求服务器根据给定的对象过滤器发送可达对象的子集。使用 --filter 时，提供的 <filter-spec> 用于部分克隆过滤器。例如，--filter=blob:none 将过滤掉所有 blob（文件内容），直到 Git 需要它们。另外，--filter=blob:limit=<size> 将过滤掉所有大小至少为 <size> 的 blob。有关过滤器规范的更多详细信息，请参阅 git-rev-list[1] 中的 --filter 选项。

--also-filter-submodules

也对仓库中的任何子模块应用部分克隆过滤器。需要 --filter 和 --recurse-submodules。可以通过设置 clone.filterSubmodules 配置选项来默认启用此功能。

--mirror

设置源仓库的镜像。这隐含 --bare。与 --bare 相比，--mirror 不仅将源的本地分支映射到目标分支，它还映射所有引用（包括远程跟踪分支、注释等），并设置一个 refspec 配置，使得所有这些引用都会被目标仓库中的 git remote update 覆盖。

-o <name>
--origin <name>

代替使用远程名称 origin 来跟踪上游仓库，使用 <name>。覆盖配置中的 clone.defaultRemoteName。

-b <name>
--branch <name>

代替将新创建的 HEAD 指向克隆仓库的 HEAD 指向的分支，而是指向 <name> 分支。在非裸仓库中，这将是将被检出的分支。 --branch 也可以接受标签，并在结果仓库中分离 HEAD 指向该提交。

--revision=<rev>

创建一个新仓库，并只获取指向给定修订版本 <rev> 的历史（仅此而已），不创建任何远程跟踪分支，也不创建任何本地分支，并将 HEAD 分离到 <rev>。参数可以是引用名称（例如 refs/heads/main 或 refs/tags/v1.0）可以解析到提交，也可以是十六进制的对象名称。此选项与 --branch 和 --mirror 不兼容。

-u <upload-pack>
--upload-pack <upload-pack>

给出此选项，并且要克隆的仓库是通过 ssh 访问的，这会指定在另一端运行的命令的非默认路径。

--template=<template-directory>

指定将从哪个目录复制模板；（参见 git-init[1] 的“模板目录”部分。）

-c <key>=<value>
--config <key>=<value>

在新建的仓库中设置一个配置变量；这在仓库初始化后立即生效，但在远程历史被拉取或任何文件被检出之前。<key> 的格式与 git-config[1] 所期望的格式相同（例如，core.eol=true）。如果为同一个键给出了多个值，每个值都将被写入配置文件。这使得添加额外的 fetch refspecs 到 origin 远程是安全的。

由于当前实现的限制，某些配置变量直到初始 fetch 和 checkout 之后才会生效。已知不会生效的配置变量是：remote.<name>.mirror 和 remote.<name>.tagOpt。请改用相应的 --mirror 和 --no-tags 选项。

--depth <depth>

创建一个*浅层*克隆，历史记录截断为指定数量的提交。隐含 --single-branch，除非给出 --no-single-branch 以拉取所有分支的最近历史。如果您想浅层克隆子模块，也请传递 --shallow-submodules。

--shallow-since=<date>

创建一个浅层克隆，其历史记录在指定时间之后。

--shallow-exclude=<ref>

创建一个浅层克隆，其历史记录排除可达指定远程分支或标签的提交。此选项可以指定多次。

--single-branch
--no-single-branch

仅克隆指向单个分支顶端的历史，该分支由 --branch 选项或远程 HEAD 指向的主分支指定。后续拉取到该仓库将只更新用于初始克隆此选项的分支的远程跟踪分支。如果远程的 HEAD 在进行 --single-branch 克隆时没有指向任何分支，则不会创建远程跟踪分支。

--tags
--no-tags

控制是否克隆标签。当给出 --no-tags 时，该选项将通过设置 remote.<remote>.tagOpt=--no-tags 配置而永久生效。这确保了未来的 git pull 和 git fetch 不会跟随任何标签。后续显式拉取标签仍然有效（参见 git-fetch[1]）。

默认情况下，会克隆标签，因此传递 --tags 通常是一个 no-op（无操作），除非它抵消了之前的 --no-tags。

可以与 --single-branch 结合使用，以克隆并维护一个除单个克隆分支外没有其他引用的分支。这对于维护最小化的默认分支克隆以进行搜索索引非常有用。

--recurse-submodules[=<pathspec>]

在创建克隆后，根据提供的 <pathspec> 初始化并克隆其中的子模块。如果未提供 <pathspec>，则所有子模块都将被初始化和克隆。此选项可以多次用于包含多个条目的 pathspec。生成的克隆具有 submodule.active 设置为提供的 pathspec，或者设置为“.”（表示所有子模块），如果没有提供 pathspec。

子模块使用其默认设置进行初始化和克隆。这等同于在克隆完成后立即运行 git submodule update --init --recursive <pathspec>。如果克隆的仓库没有工作树/检出（即，如果给出 --no-checkout/-n、--bare 或 --mirror 中的任何一个），则忽略此选项。

--shallow-submodules
--no-shallow-submodules

所有被克隆的子模块都将是浅层的，深度为 1。

--remote-submodules
--no-remote-submodules

所有被克隆的子模块将使用子模块的远程跟踪分支状态来更新子模块，而不是父项目的记录的 SHA-1。等同于传递 --remote 给 git submodule update。

--separate-git-dir=<git-dir>

不将克隆的仓库放置在其应有的位置，而是将其放置在指定目录，然后创建一个与文件系统无关的 Git 符号链接。结果是 Git 仓库可以与工作树分离。

--ref-format=<ref-format>

为仓库指定给定的 ref 存储格式。有效值为

  • files 表示带有 packed-refs 的松散文件。这是默认值。

  • reftable 表示 reftable 格式。此格式是实验性的，其内部结构可能会更改。

-j <n>
--jobs <n>

同时获取的子模块数量。默认为 submodule.fetchJobs 选项。

<repository>

要克隆的（可能是远程的）<repository>。有关指定仓库的更多信息，请参阅下面的 GIT URLS 部分。

<directory>

要克隆到的新目录的名称。如果未明确给出 <directory>，则使用源仓库的“人类可读”部分（对于 /path/to/repo.git 为 repo，对于 host.xz:foo/.git 为 foo）。克隆到现有目录仅在目录为空时才允许。

--bundle-uri=<uri>

在从远程拉取之前，从给定的 <uri> 拉取一个 bundle（包），并将数据解包到本地仓库。bundle 中的 refs 将存储在隐藏的 refs/bundle/* 命名空间下。此选项与 --depth、--shallow-since 和 --shallow-exclude 不兼容。

GIT URLS

通常，URL 包含有关传输协议、远程服务器地址和仓库路径的信息。根据传输协议，其中一些信息可能不存在。

Git 支持 ssh、git、http 和 https 协议（此外，ftp 和 ftps 也可用于获取，但这效率低下且已弃用；请勿使用它们）。

原生传输（即 git:// URL）不进行身份验证，在不安全的网络上应谨慎使用。

可以使用以下语法：

  • ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>

  • git://<host>[:<port>]/<path-to-git-repo>

  • http[s]://<host>[:<port>]/<path-to-git-repo>

  • ftp[s]://<host>[:<port>]/<path-to-git-repo>

ssh 协议还可以使用另一种类似 scp 的语法：

  • [<user>@]<host>:/<path-to-git-repo>

仅当第一个冒号之前没有斜杠时，此语法才会被识别。这有助于区分包含冒号的本地路径。例如，本地路径 foo:bar 可以指定为绝对路径或 ./foo:bar 以避免被误解为 ssh url。

ssh 和 git 协议还支持 ~<username> 扩展

  • ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>

  • git://<host>[:<port>]/~<user>/<path-to-git-repo>

  • [<user>@]<host>:~<user>/<path-to-git-repo>

对于 Git 本身也支持的本地仓库，可以使用以下语法

  • /path/to/repo.git/

  • file:///path/to/repo.git/

这两种语法在大多数情况下是等效的，除了前者隐含 --local 选项。

git clone、git fetch 和 git pull（但不是 git push）也将接受一个合适的 bundle 文件。参见 git-bundle[1]。

当 Git 不知道如何处理某种传输协议时，它会尝试使用 remote-<transport> 远程助手（如果存在）。要显式请求一个远程助手，可以使用以下语法

  • <transport>::<address>

其中 <address> 可以是路径、服务器和路径，或者是特定远程辅助工具可识别的任意类 URL 字符串。有关详细信息，请参阅 gitremote-helpers[7]。

如果存在大量名称相似的远程仓库，并且您想为它们使用不同的格式（以便您使用的 URL 将被重写为可用的 URL），您可以创建以下形式的配置节：

	[url "<actual-url-base>"]
		insteadOf = <other-url-base>

例如，有了这个：

	[url "git://git.host.xz/"]
		insteadOf = host.xz:/path/to/
		insteadOf = work:

“work:repo.git”或“host.xz:/path/to/repo.git”这样的 URL 在任何接受 URL 的上下文中都将被重写为“git://git.host.xz/repo.git”。

如果只想重写推送的 URL，可以创建以下形式的配置节：

	[url "<actual-url-base>"]
		pushInsteadOf = <other-url-base>

例如，有了这个：

	[url "ssh://example.org/"]
		pushInsteadOf = git://example.org/

像“git://example.org/path/to/repo.git”这样的 URL 将被重写为“ssh://example.org/path/to/repo.git”用于推送，但拉取仍将使用原始 URL。

示例

  • 从上游克隆

    $ git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
$ cd my-linux
$ make

  • 进行本地克隆，从当前目录借用，而不检出

    $ git clone -l -s -n . ../copy
$ cd ../copy
$ git show-branch

  • 从上游克隆，同时从现有本地目录借用

    $ git clone --reference /git/linux.git \
	git://git.kernel.org/pub/scm/.../linux.git \
	my-linux
$ cd my-linux

  • 创建裸仓库以公开您的更改

    $ git clone --bare -l /home/proj/.git /pub/scm/proj.git

  • 从不同用户的本地仓库克隆

    $ git clone --no-local /home/otheruser/proj.git /pub/scm/proj.git

配置

本节中以下所有内容均从 git-config[1] 文档中选择性地包含。内容与彼处相同：

init.templateDir

指定将从哪个目录复制模板。（参见 git-init[1] 的“模板目录”部分。）

init.defaultBranch

允许覆盖默认分支名称，例如在初始化新仓库时。

init.defaultObjectFormat

允许覆盖新存储库的默认对象格式。请参阅 git-init[1] 中的 --object-format=。命令行选项和 GIT_DEFAULT_HASH 环境变量都优先于此配置。

init.defaultRefFormat

允许覆盖新存储库的默认 ref 存储格式。请参阅 git-init[1] 中的 --ref-format=。命令行选项和 GIT_DEFAULT_REF_FORMAT 环境变量都优先于此配置。

clone.defaultRemoteName

克隆仓库时创建的远程的名称。默认为 origin。可以通过传递 --origin 命令行选项来覆盖。

clone.rejectShallow

拒绝克隆一个仓库，如果它是一个浅层仓库；这可以通过在命令行上传递 --reject-shallow 选项来覆盖。

clone.filterSubmodules

如果提供了部分克隆过滤器（参见 git-rev-list[1] 中的 --filter）并且使用了 --recurse-submodules，则也对子模块应用过滤器。

GIT

Git[1] 套件的一部分