简体中文 ▾ 主题 ▾ 最新版本 ▾ git-clone 上次更新于 2.49.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 除了会将远程主分支合并到当前主分支（如果有的话）之外，还会进行更新（当给出 --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 操作（例如 git commit）自动调用 git maintenance run --auto 所移除。（请参阅 git-maintenance[1]。）如果这些对象被移除并且被克隆仓库引用，则克隆仓库将损坏。

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

如果你想解除通过 --shared 克隆的仓库对其源仓库的依赖，只需运行 git repack -a，将所有对象从源仓库复制到克隆仓库的 pack 中即可。

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

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

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

--dissociate

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

-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）。如果为同一个键提供了多个值，则每个值都将写入配置文件。例如，这使得向 origin 远程添加额外的 fetch refspec 成为安全的操作。

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

--depth <depth>

创建一个浅克隆，历史记录被截断到指定的提交数量。除非指定 --no-single-branch 以获取所有分支尖端的历史记录，否则隐含 --single-branch。如果要浅层克隆子模块，也要传递 --shallow-submodules。

--shallow-since=<date>

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

--shallow-exclude=<ref>

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

--[no-]single-branch

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

--[no-]tags

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

默认情况下，标签会被克隆，因此传递 --tags 通常是空操作，除非它取消了之前的 --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 中的任何一个），则此选项将被忽略。

--[no-]shallow-submodules

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

--[no-]remote-submodules

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

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

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

--ref-format=<ref-format>

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

  • 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> 获取一个包，并将数据解包到本地仓库中。包中的引用将存储在隐藏的 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，也将接受合适的包文件。请参阅 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

允许覆盖新仓库的默认引用存储格式。请参阅 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] 套件的一部分

scroll-to-top