设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
修补
调试
邮件
外部系统
服务器管理
指南
管理
管道命令
- 2.47.0 10/06/24
- 2.46.1 → 2.46.2 无更改
- 2.46.0 07/29/24
- 2.45.1 → 2.45.2 无更改
- 2.45.0 04/29/24
- 2.44.1 → 2.44.2 无更改
- 2.44.0 02/23/24
- 2.43.1 → 2.43.5 无更改
- 2.43.0 11/20/23
- 2.41.1 → 2.42.3 无更改
- 2.41.0 06/01/23
- 2.38.1 → 2.40.3 无更改
- 2.38.0 10/02/22
- 2.36.1 → 2.37.7 无更改
- 2.36.0 04/18/22
- 2.35.1 → 2.35.8 无更改
- 2.35.0 01/24/22
- 2.32.1 → 2.34.8 无更改
- 2.32.0 06/06/21
- 2.30.2 → 2.31.8 无更改
- 2.30.1 02/08/21
- 2.30.0 12/27/20
- 2.29.1 → 2.29.3 无更改
- 2.29.0 10/19/20
- 2.28.1 无更改
- 2.28.0 07/27/20
- 2.27.1 无更改
- 2.27.0 06/01/20
- 2.25.1 → 2.26.3 无更改
- 2.25.0 01/13/20
- 2.23.1 → 2.24.4 无更改
- 2.23.0 08/16/19
- 2.22.2 → 2.22.5 无更改
- 2.22.1 08/11/19
- 2.22.0 06/07/19
- 2.21.1 → 2.21.4 无更改
- 2.21.0 02/24/19
- 2.18.1 → 2.20.5 无更改
- 2.18.0 06/21/18
- 2.17.0 → 2.17.6 无更改
- 2.16.6 12/06/19
- 2.15.4 无更改
- 2.14.6 12/06/19
- 2.13.7 05/22/18
- 2.12.5 无更改
- 2.11.4 09/22/17
- 2.10.5 无更改
- 2.9.5 07/30/17
- 2.8.6 07/30/17
- 2.7.6 07/30/17
- 2.4.12 → 2.6.7 无更改
- 2.3.10 09/28/15
- 2.1.4 → 2.2.3 无更改
- 2.0.5 12/17/14
概要
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
包含符号链接或是一个符号链接,则克隆将失败。这是一种安全措施,可以防止意外地通过解除符号链接的引用来复制文件。注意:此操作可能会与对源仓库的并发修改发生竞争,类似于在修改
src
时运行cp -r src dst
。 -
--no-hardlinks
-
强制从本地文件系统上的仓库进行克隆过程,以复制
.git/objects
目录下的文件,而不是使用硬链接。如果你试图备份你的仓库,这可能是有利的。 -
-s
-
当要克隆的仓库位于本地机器上时,自动设置
.git/objects/info/alternates
以与源仓库共享对象,而不是使用硬链接。生成的仓库最初没有自己的对象。注意:这是一个可能很危险的操作;除非你了解它的作用,否则不要使用它。如果你使用此选项克隆仓库,然后在源仓库中删除分支(或使用任何其他 Git 命令使任何现有提交失去引用),则一些对象可能会失去引用(或成为悬空对象)。这些对象可能会被正常的 Git 操作(例如
git commit
)删除,这些操作会自动调用git maintenance run --auto
。(见 git-maintenance[1]。)如果这些对象被删除并且被克隆的仓库引用,那么克隆的仓库将变得损坏。注意,在使用
--shared
克隆的仓库中运行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> 时,它们都会按命令行上列出的顺序发送到另一方。 -
-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
不仅将源代码的本地分支映射到目标的本地分支,它还映射所有 ref(包括远程跟踪分支、注释等)并设置 refspec 配置,以便所有这些 ref 都被目标仓库中的git remote update
覆盖。 -
-o
<name> -
--origin
<name> -
不使用远程名称
origin
来跟踪上游仓库,而是使用 <name>。覆盖来自配置的clone.defaultRemoteName
。 -
-b
<name> -
--branch
<name> -
不将新创建的 HEAD 指向克隆仓库的 HEAD 所指向的分支,而是指向 <name> 分支。在非裸仓库中,这是将要签出的分支。
--branch
也可以接受标签,并在结果仓库中将 HEAD 分离到该提交。 -
-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=
<revision> -
创建一个浅层克隆,其历史记录中不包含从指定的远程分支或标签可到达的提交。此选项可以多次指定。
-
--
[no-
]single-branch
-
仅克隆通向单个分支尖端的历史记录,该分支由
--branch
选项指定或由主分支远程的HEAD
指向。对结果仓库的进一步获取只会更新用于初始克隆的分支的远程跟踪分支。如果克隆--single-branch
时远程的HEAD
没有指向任何分支,则不会创建远程跟踪分支。 -
--no-tags
-
不要克隆任何标签,并在配置中设置
remote.<remote>.tagOpt=--no-tags
,确保未来的git pull
和git fetch
操作不会跟踪任何标签。随后的显式标签获取仍然有效(参见 git-fetch[1])。可以与
--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> -
为仓库指定给定的 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 中的 ref 将存储在隐藏的
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/
这两种语法基本等效,只是前者意味着 --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-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] 套件的一部分