clone
TIP
使用git clone
命令时,可能会遇到各种问题。
通常,这些问题的解决方案包括将Git环境配置为使用正确的代理服务器,浅层克隆存储库,将Git配置为使用SChannel加密后端,以及设置--system
core.longpaths
参数。
此外,应该优化存储库的性能以获得更好的克隆性能。
克隆一个版本库到一个新的目录中
语法
- git clone <版本库的网址> <本地目录名>
实例
支持多种协议,除了HTTP(s)以外,还支持SSH、Git、本地文件协议等
- git clone http[s]://example.com/path/to/repo.git/
- git clone ssh://example.com/path/to/repo.git/
- git clone git://example.com/path/to/repo.git/
- git clone /opt/git/project.git
- git clone file:///opt/git/project.git
- git clone ftp[s]://example.com/path/to/repo.git/
- git clone rsync://example.com/path/to/repo.git/
SSH协议另一种写法
- git clone [user@]example.com:path/to/repo.git/
从上游克隆。
- git clone git://git.kernel.org/pub/scm/.../linux.git my-linux
做一个借用当前目录的本地克隆,而不检查东西。
- git clone -l -s -n . ../copy
从上游克隆,同时借用现有的本地目录。
- git clone --reference /git/linux.git \
- git://git.kernel.org/pub/scm/.../linux.git \
- my-linux
创建一个裸仓库来向公众发布你的更改。
- git clone --bare -l /home/proj/.git /pub/scm/proj.git
描述
将存储库克隆到新创建的目录中,为克隆存储库中的每个分支创建远程跟踪分支(使用 git branch --remotes
可见),并创建并签出从克隆存储库的当前活动分支派生的初始分支。
克隆之后,不带参数的纯 git fetch
将更新所有远程跟踪分支,并且不带参数的 git pull
将另外将远程master分支合并到当前的master分支中
通过在 refs/remotes/origin
下创建对远程分支头的引用并初始化 remote.origin.url
和 remote.origin.fetch
配置变量来实现此默认配置。
选项
- -l,--local
-
当要从中进行克隆的存储库位于本地计算机上时,此标志将绕过常规的
Git aware
传输机制,并通过在对象和引用目录下创建HEAD以及所有内容的副本来克隆存储库。.git/objects/
目录下的文件经过硬链接以尽可能节省空间。 -
如果将存储库指定为本地路径(例如
/path/to/repo
),则这是默认设置,而--local
本质上是no-op。如果将存储库指定为URL,则将忽略此标志(并且我们永远不会使用本地优化)。当给出/path/to/repo
时,指定--no-local
将覆盖默认值,而改用常规Git传输。 -
注意:此操作可以与对源存储库的并发修改竞争,类似于在修改
src
时运行cp -r src dst
。 - --no-hardlinks
-
强制从本地文件系统上的存储库进行克隆过程,以复制 .git/objects 目录下的文件,而不使用硬链接。如果您要备份存储库,则这可能是理想的。
- -s,--shared
-
当要克隆的存储库位于本地计算机上时,而不是使用硬链接,而是自动设置
.git/objects/info/alternates
与源存储库共享对象。生成的存储库开始时没有其自己的任何对象。 -
注意:这可能是一种危险的操作;除非你了解它的作用,否则不要使用它。如果使用此选项克隆存储库,然后在源存储库中删除分支(或使用任何其他使任何现有提交不被引用的Git命令),则某些对象可能会变得不被引用。可以通过正常的Git操作(如
git commit
)删除这些对象,这些操作会自动调用git maintenance run --auto
.如果这些对象被删除并被克隆的存储库引用,则克隆的存储库将损坏。 -
注意,在使用
--shared
克隆的存储库中运行不带--local
的git repack
命令会将源存储库中的对象复制到克隆存储库中的包中,从而消除使用clone --shared
节省的磁盘空间。不过运行git gc
是安全的,它默认使用--local
选项 -
如果要断开用
--shared
克隆的存储库对其源存储库的依赖关系,只需运行git repack -a
即可将源存储库中的所有对象复制到克隆存储库中的一个包中。 - --reference[-if-able] <repository>
-
如果参考存储库位于本地计算机上,则自动设置
.git/objects/info/alternates
以从参考存储库获取对象。使用现有的存储库作为备用存储库将需要从要克隆的存储库中复制较少的对象,从而降低了网络和本地存储成本。使用--reference-if-able
时,不存在的目录会被警告跳过,而不是中止克隆。 -
注意:请参阅
--shared
的注释,以及--dissociate
- --dissociate
-
从使用
--reference
选项指定的引用存储库中借用对象,只是为了减少网络传输,并在克隆后通过对借用的对象进行必要的本地复制来停止从中借用。当从已经从另一个存储库借用对象的存储库进行本地克隆时,也可以使用此选项:新存储库将从同一个存储库借用对象,并且该选项可用于停止借用。 - -q,--quiet
-
Operate quietly. Progress is not reported to the standard error stream
- -v,--verbose
-
Run verbosely. Does not affect the reporting of progress status to the standard error stream
- --progress
-
除非指定了
--quiet
,否则默认情况下,将状态错误报告到标准错误流时,将在标准错误流上报告该状态。即使标准错误流未定向到终端,此标志也会强制显示进度状态。 - --server-option=<option>
-
使用协议版本 2 进行通信时将给定字符串传输到服务器。给定字符串不能包含 NUL 或 LF 字符。服务器对服务器选项(包括未知选项)的处理是特定于服务器的。当给出多个
--server-option=<option>
时,它们都按照命令行中列出的顺序发送到另一端。 - -n,--no-checkout
-
克隆完成后不对HEAD进行检查。
- --[no-]reject-shallow
-
如果源存储库是浅存储库,则失败。所述
clone.rejectShallow
配置变量可以用来指定默认。 - --bare
-
制作一个
bare
Git存储库。也就是说,不要创建<directory>
并将管理文件放置在<directory>/.git
,$GIT_DIR
将<directory>
本身设置为$GIT_DIR
。显然这意味着--no-checkout
,因为没有地方可以检出工作树。同样,将远程的分支头直接复制到相应的本地分支头,而无需将它们映射到refs/remotes/origin/
。使用此选项时,不会创建远程跟踪分支或相关的配置变量。 - --sparse
-
使用稀疏签出,最初只存在顶级目录中的文件
- --filter=<filter-spec>
-
使用部分克隆功能,并请求服务器根据给定的对象过滤器发送可访问对象的子集。使用
--filter
时,提供的<filter-spec>
用于部分克隆过滤器。 - --also-filter-submodules
-
还将部分克隆过滤器应用于存储库中的任何子模块。需要
--filter
和--recurse-submodules
。这可以通过设置clone.filterSubmodules
配置选项默认打开。 - --mirror
-
设置源存储库的镜像。与
--bare
相比--mirror
不仅将源的本地分支映射到目标的本地分支,还映射所有引用(包括远程跟踪分支,注释等),并设置一个refspec配置,以便所有这些引用被目标存储库中的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>
-
指定将使用模板的目录
- -c <key>=<value>,--config <key>=<value>
-
在新创建的存储库中设置配置变量;这将在初始化存储库之后,但在获取远程历史记录或签出任何文件之前立即生效。
-
由于当前实施方式的限制,某些配置变量要等到初始获取和签出后才能生效。已知不会生效的配置变量是:
remote.<name>.mirror
和remote.<name>.tagOpt
。请改用相应的--mirror
和--no-tags
- --depth <depth>
-
创建一个
shallow
克隆,其历史记录被截断为指定的提交数。表示--single-branch
,除非给出--no-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
操作不会跟随任何标签。随后的显式标签提取仍然有效 -
可以与 -
-single-branch
一起使用,以克隆和维护除单个克隆分支之外没有其他引用的分支。例如,这对于维护某些存储库的默认分支的最小克隆以进行搜索索引很有用。 - --recurse-submodules[=
] -
创建克隆后,根据提供的pathspec初始化并克隆其中的子模块。如果未提供pathspec,则将初始化并克隆所有子模块。对于由多个条目组成的路径规范,可以多次赋予此选项。所得克隆的
submodule.active
设置为提供的pathspec或’.'。(表示所有子模块)(如果未提供pathspec)。 -
子模块使用其默认设置进行初始化和克隆。这等效于克隆完成后立即运行
git submodule update --init --recursive <pathspec>
。如果克隆库不具有worktree /结帐忽略此选项(即如果任何--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仓库可以与工作树分离。
- -j <n>,--jobs <n>
-
同时获取的子模块数。默认为
submodule.fetchJobs
选项。