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， 则此标志被忽略（我们从不使用本地优化）。指定 --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 以与源仓库共享对象。生成的仓库开始时没有任何自己的对象。 +
TIP
这是一项可能危险的操作；不要使用它，
除非您理解其作用。如果您使用此选项克隆仓库， 然后在源仓库中删除分支（或使用任何使现有提交不被引用的其他 Git 命令）， 某些对象可能变为不被引用（或悬空）。 这些对象可能被正常的 Git 操作（如 git commit）移除， 这些操作会自动调用 git maintenance run --auto。 （参见 git-maintenance(1)。） 如果这些对象被移除且被克隆仓库引用，则克隆仓库将损坏。 + 请注意，在使用 --shared 克隆的仓库中运行不带 --local 选项的 git repack 会将对象从源仓库复制到克隆仓库的包中，移除 clone --shared 的磁盘空间节省。 然而，运行 git gc 是安全的，默认使用 --local 选项。 + 如果您想打破使用 --shared 克隆的仓库对其源仓库的依赖， 只需运行 git repack -a 即可将所有对象从源仓库复制到克隆仓库的包中。
--reference=<repository>
--reference-if-able=<repository>
如果引用仓库 <repository> 在本地机器上， 自动设置 .git/objects/info/alternates 以从引用仓库 <repository> 获取对象。使用已存在的仓库作为替代 将需要从被克隆仓库复制更少的对象，减少网络和本地存储成本。 使用 --reference-if-able 时，不存在的目录将被跳过并发出警告， 而不是中止克隆。 +
TIP
参见 --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
--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=auto，过滤器规范通过 'promisor-remote' 协议 （参见 gitprotocol-v2(5)）自动确定， 通过组合服务器为客户端接受的 promisor 远程仓库公布的过滤器规范 （参见 git-config(1) 中的 promisor.acceptFromServer 配置选项）。 这允许服务器为可用的 promisor 远程仓库建议最佳过滤器。 + 与其他过滤器规范一样，"auto" 值会被持久化到配置中。 这确保未来的获取操作将继续适应服务器的当前建议。 + 有关所有其他可用过滤器规范的详细信息， 请参阅 git-rev-list 中的 --filter=<filter-spec> 选项。 + 例如，--filter=blob:none 将过滤掉所有 blob（文件内容），直到 Git 需要时。 同样，--filter=blob:limit=<size> 将过滤掉大小至少为 <size> 的所有 blob。
--also-filter-submodules
还将部分克隆过滤器应用于仓库中的任何子模块。 需要 --filter 和 --recurse-submodules。 可通过设置 clone.filterSubmodules 配置选项默认开启。
--mirror
设置源仓库的镜像。这意味着 --bare。 与 --bare 相比，--mirror 不仅将源的本地分支映射到目标的本地分支， 还映射所有引用（包括远程跟踪分支、笔记等）， 并设置引用规范配置，使所有这些引用在目标仓库中被 git remote update 覆盖。
-o<name>
--origin=<name>
使用 <name> 代替远程名称 origin 来跟踪上游仓库。 覆盖配置中的 clone.defaultRemoteName。
-b<name>
--branch=<name>
将新创建的 HEAD 指向 <name> 分支， 而不是克隆仓库 HEAD 指向的分支。在非裸仓库中，这将是被检出的分支。 --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) 的 "TEMPLATE DIRECTORY" 部分。）
-c<key>=<value>
--config=<key>=<value>
在新创建的仓库中设置配置变量； 这在仓库初始化后立即生效，但在获取远程历史记录或检出任何文件之前。 <key> 的格式与 git-config(1) 期望的格式相同 （例如 core.eol=true）。如果对同一键给出多个值， 每个值将被写入配置文件。这使得例如向 origin 远程添加额外的获取引用规范是安全的。 + 由于当前实现的限制，某些配置变量在初始获取和检出之后才会生效。 已知不会生效的配置变量是： 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-tags。 + 可与 --single-branch 结合使用，以克隆和维护一个除单个克隆分支外没有其他引用的分支。 这对于维护某些仓库默认分支的最小克隆以进行搜索索引很有用。
--recurse-submodules[=<pathspec>]
创建克隆后，根据提供的 <pathspec> 初始化并克隆其中的子模块。 如果未提供 =<pathspec>，则初始化并克隆所有子模块。 对于包含多个条目的路径规范，可多次给出此选项。 结果克隆将 submodule.active 设置为提供的路径规范， 如果未提供路径规范则设置为 "."（表示所有子模块）。 + 子模块使用其默认设置初始化和克隆。这等同于在克隆完成后立即运行 git submodule update --init --recursive <pathspec>。 如果克隆的仓库没有工作树/检出（即给出了 --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-dir>
不将克隆的仓库放在其应在的位置，而是将克隆的仓库放在指定目录， 然后创建一个与文件系统无关的 Git 符号链接到那里。 结果是 Git 仓库可以与工作树分离。
--ref-format=<ref-format>
指定仓库的引用存储格式。有效值为： + files;; 用于带 packed-refs 的松散文件。 ifndef::with-breaking-changes[] 这是默认值。 endif::with-breaking-changes[] reftable;; 用于 reftable 格式。 ifdef::with-breaking-changes[] 这是默认值。 endif::with-breaking-changes[]
-j<n>
--jobs=<n>
同时获取的子模块数量。 默认为 submodule.fetchJobs 选项。
<repository>:: 要克隆的（可能是远程的）<repository>。有关指定仓库的更多信息， 请参阅下面的 <<URLS,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-clone: 1
示例
- 从上游克隆：
GIT URLS[[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/
ifndef::git-clone[] 这两种语法基本等效，但在克隆时，前者意味着 --local 选项。详情请参阅 git-clone(1)。 endif::git-clone[]
ifdef::git-clone[] 这两种语法基本等效，但前者意味着 --local 选项。 endif::git-clone[]
git clone、git fetch 和 git pull（但不是 git push）也接受合适的包文件。参见 git-bundle(1)。
当 Git 不知道如何处理某个传输协议时，它会尝试使用 remote-<transport> 远程助手（如果存在）。 要显式请求远程助手，可使用以下语法：
<transport>::<address>
其中 <address> 可以是路径、服务器和路径，或被调用的特定远程助手识别的任意类似 URL 的字符串。详情请参阅 gitremote-helpers(7)。
如果有大量类似命名的远程仓库，并且您想为它们使用不同的格式（使得您使用的 URL 被重写为有效的 URL）， 您可以创建以下形式的配置部分：
[verse]
[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，可以创建以下形式的配置部分：
## 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。
+
$ make
- 进行本地克隆，从当前目录借用而不检出内容：
$ git show-branch
- 从上游克隆，同时从现有本地目录借用：
$ 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) 文档中选择性包含。内容与那里找到的相同：
:see-git-init: ifndef::git-init[] :see-git-init: （参见 git-init(1) 的 "TEMPLATE DIRECTORY" 部分。） endif::[]
init.templateDir:: 指定将从中复制模板的目录。{see-git-init} init.defaultBranch:: 允许覆盖默认分支名称，例如在初始化新仓库时。 init.defaultObjectFormat:: 允许覆盖新仓库的默认对象格式。参见 git-init(1) 中的 --object-format=。 命令行选项和 GIT_DEFAULT_HASH 环境变量均优先于此配置。 init.defaultRefFormat:: 允许覆盖新仓库的默认引用存储格式。 参见 git-init(1) 中的 --ref-format=。 命令行选项和 GIT_DEFAULT_REF_FORMAT 环境变量均优先于此配置。
init.defaultSubmodulePathConfig:: 一个布尔值，指定 git init 和 git clone 是否应自动将 extensions.submodulePathConfig 设置为 true。 这允许所有新仓库自动使用子模块路径扩展。未设置时默认为 false。
clone.defaultRemoteName:: 克隆仓库时创建的远程名称。默认为 origin。 ifdef::git-clone[] 可通过传递 --origin 命令行选项覆盖。 endif::[] ifndef::git-clone[] 可通过向 git-clone(1) 传递 --origin 命令行选项覆盖。 endif::[]
clone.rejectShallow:: 如果仓库是浅仓库则拒绝克隆；可通过在命令行传递 --reject-shallow 选项覆盖。 ifndef::git-clone[] 参见 git-clone(1)。 endif::[]
clone.filterSubmodules:: 如果提供了部分克隆过滤器（参见 git-rev-list(1) 中的 --filter） 并使用了 --recurse-submodules，则还将过滤器应用于子模块。
Git
git(1) 套件的一部分