English ▾ 主题 ▾ 最新版本 ▾ git-clone 上次更新于 2.49.0

名称

git-clone - 将存储库克隆到新目录中

概要

git clone [--template=<模板目录>] [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror] [-o <名称>] [-b <名称>] [-u <upload-pack>] [--reference <存储库>] [--dissociate] [--separate-git-dir <git-dir>] [--depth <深度>] [--[no-]single-branch] [--[no-]tags] [--recurse-submodules[=<路径规范>]] [--[no-]shallow-submodules] [--[no-]remote-submodules] [--jobs <n>] [--sparse] [--[no-]reject-shallow] [--filter=<filter-spec>] [--also-filter-submodules]] [--] <存储库> [<目录>]

描述

将存储库克隆到新创建的目录中，为克隆存储库中的每个分支创建远程跟踪分支（使用 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，则忽略此标志（并且我们从不使用本地优化）。指定 --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]。）如果这些对象被删除并且被克隆存储库引用，则克隆存储库将损坏。

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

如果您想打破使用 --shared 克隆的存储库对其源存储库的依赖性，您可以简单地运行 git repack -a 以将源存储库中的所有对象复制到克隆存储库中的一个包中。

--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>。覆盖 config 中的 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 远程添加额外的获取 refspec 是安全的。

由于当前实现的限制，一些配置变量在初始获取和检出之后才会生效。已知无法生效的配置变量有：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>，则会初始化和克隆所有子模块。可以多次给出此选项，以用于包含多个条目的路径规范。结果克隆的 submodule.active 设置为提供的路径规范，或者如果未提供路径规范，则设置为 "."（表示所有子模块）。

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

--[no-]shallow-submodules

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

--[no-]remote-submodules

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

--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>，则使用源仓库的“类人”部分（repo 用于 /path/to/repo.git，foo 用于 host.xz:foo/.git）。只有当目录为空时，才允许克隆到现有目录中。

--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>

另一种类似 scp 的语法也可以用于 ssh 协议

  • [<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"。

如果只想重写 push 的 URL，可以创建一个如下形式的配置部分

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

例如，对于以下配置：

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

对于 push，类似于 "git://example.org/path/to/repo.git" 的 URL 将被重写为 "ssh://example.org/path/to/repo.git"，但 pull 仍将使用原始 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