简体中文 ▾ 主题 ▾ 最新版本 ▾ 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 本质上是一个空操作。如果仓库被指定为 URL，则此标志会被忽略（且绝不会使用本地优化）。当给出 /path/to/repo 时，指定 --no-local 将覆盖默认值，转而使用常规的 Git 传输机制。

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

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

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

--no-hardlinks

强制从本地文件系统上的仓库进行克隆时，复制 .git/objects 目录下的文件，而不是使用硬链接。如果您正在尝试备份仓库，这可能是理想的选择。

-s
--shared

当要克隆的仓库位于本地机器上时，不使用硬链接，而是自动设置 .git/objects/info/alternates 以与源仓库共享对象。生成的仓库在开始时没有任何自己的对象。

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

请注意，在通过 --shared 克隆的仓库中运行不带 --local 选项的 git repack 将把对象从源仓库复制到克隆仓库的包中，从而抵消了 clone --shared 节省的磁盘空间。但是，运行默认使用 --local 选项的 git gc 是安全的。

如果您想断开使用 --shared 克隆的仓库对其源仓库的依赖，可以简单地运行 git repack -a，将所有对象从源仓库复制到克隆仓库的包中。

--reference[-if-able] <仓库>

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

注意：请参阅 --shared 选项的注意，以及 --dissociate 选项。

--dissociate

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

-q
--quiet

静默操作。不向标准错误流报告进度。

-v
--verbose

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

--progress

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

--server-option=<选项>

在使用协议版本 2 进行通信时，将给定字符串传输到服务器。给定的字符串不能包含 NUL 或 LF 字符。服务器对服务器选项（包括未知选项）的处理取决于具体服务器。当给出多个 --server-option=<选项> 时，它们将按照命令行中列出的顺序全部发送到另一端。当命令行中没有给出 --server-option= 时，将改用配置变量 remote.<名称>.serverOption 的值。

-n
--no-checkout

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

--[no-]reject-shallow

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

--bare

创建一个裸 (bare) Git 仓库。也就是说，不是创建 <目录> 并将管理文件放在 <目录>/.git 中，而是将 <目录> 本身作为 $GIT_DIR。这显然暗示了 --no-checkout，因为没有地方检出工作区。此外，远程的分支头会直接复制到相应的本地分支头，而不会将它们映射到 refs/remotes/origin/。使用此选项时，既不会创建远程跟踪分支，也不会创建相关的配置变量。

--sparse

采用稀疏检出，初始仅包含顶级目录中的文件。可以使用 git-sparse-checkout[1] 命令根据需要扩展工作目录。

--filter=<过滤器规格>

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

--also-filter-submodules

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

--mirror

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

-o <名称>
--origin <名称>

不使用远程名称 origin 来跟踪上游仓库，而是使用 <名称>。这将覆盖配置中的 clone.defaultRemoteName。

-b <名称>
--branch <名称>

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

--revision=<修订号>

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

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

如果给定，且克隆的仓库是通过 ssh 访问的，这会为另一端运行的命令指定非默认路径。

--template=<模板目录>

指定使用模板的目录；（参见 git-init[1] 的 "TEMPLATE DIRECTORY" 章节。）

-c <键>=<值>
--config <键>=<值>

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

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

--depth <深度>

创建一个浅层 (shallow) 克隆，其历史记录被截断为指定的提交次数。暗示了 --single-branch，除非指定 --no-single-branch 以获取所有分支尖端附近的历史。如果您想浅层地克隆子模块，请同时传递 --shallow-submodules。

--shallow-since=<日期>

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

--shallow-exclude=<引用>

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

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

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

--tags
--no-tags

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

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

可以与 --single-branch 结合使用，以克隆并维护一个除了单个克隆分支外没有其他引用的分支。这在例如为搜索索引维护某些仓库默认分支的最小克隆时很有用。

--recurse-submodules[=<路径规格>]

创建克隆后，根据提供的 <路径规格> 初始化并克隆其中的子模块。如果没有提供 =<路径规格>，则初始化并克隆所有子模块。对于由多个条目组成的路径规格，此选项可以多次指定。生成的克隆会将 submodule.active 设置为提供的路径规格，如果未提供路径规格，则设置为 "."（表示所有子模块）。

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

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

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

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

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

--separate-git-dir=<git 目录>

不将克隆的仓库放在它应该在的地方，而是放在指定的目录中，然后建立一个与文件系统无关的 Git 符号链接到那里。结果是 Git 仓库可以与工作树分离。

--ref-format=<引用格式>

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

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

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

-j <n>
--jobs <n>

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

<仓库>

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

<目录>

克隆到的新目录的名称。如果没有显式给出 <目录>，则使用源仓库的“类人”部分（对于 /path/to/repo.git 为 repo，对于 host.xz:foo/.git 为 foo）。只有当目录为空时，才允许克隆到现有目录中。

--bundle-uri=<uri>

在从远程获取之前，先从给定的 <uri> 获取一个 bundle 并在本地仓库中拆包。bundle 中的引用将存储在隐藏的 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] 的 "TEMPLATE DIRECTORY" 章节。）

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] 套件的一部分