8.2.3.1. 稀疏检出¶

从1.7.0版本开始Git提供稀疏检出的功能。所谓稀疏检出就是本地版本库检出时不检出全部，只将指定的文件从本地版本库检出到工作区，而其他未指定的文件则不予检出（即使这些文件存在于工作区，其修改也会被忽略）。

要想实现稀疏检出的功能，必须同时设置core.sparseCheckout配置变量，并存在文件.git/info/sparse-checkout。即首先要设置Git配置变量core.sparseCheckout为true，然后编辑.git/info/sparse-checkout文件，将要检出的目录或文件的路径写入其中。其中文件.git/info/sparse-checkout的格式就和.gitignore文件格式一样，路径可以使用通配符。

稀疏检出是如何实现的呢？实际上Git在index（即暂存区）中为每个文件提供一个名为skip-worktree标志位，缺省这个标识位处于关闭状态。如果该标识位开启，则无论工作区对应的文件存在与否，或者是否被修改，Git都认为工作区该文件的版本是最新的、无变化。Git通过配置文件.git/info/sparse-checkout定义一个要检出的目录和/或文件列表，当前Git的git read-tree命令及其他基于合并的命令（git merge，git checkout等等）能够根据该配置文件更新index中文件的skip-worktree标志位，实现版本库文件的稀疏检出。

先来在工作区/path/to/my/workspace中创建一个示例版本库sparse1，创建后的sparse1版本库中包含如下内容：

$ ls -F
doc1/ doc2/ doc3/
$ git ls-files -s -v
H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0     doc1/readme.txt
H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0     doc2/readme.txt
H 100644 ce013625030ba8dba906f756967f9e9ca394464a 0     doc3/readme.txt

即版本库sparse1中包含三个目录doc1、doc2和doc3。命令git ls-files的-s参数用于显示对象的SHA1哈希值以及所处的暂存区编号。而-v参数则还会显示工作区文件的状态，每一行命令输出的第一个字符即是文件状态：字母H表示文件已被暂存，如果是字母S则表示该文件skip-worktree标志位已开启。

下面我们就来体验一下稀疏检出的功能。

• 修改版本库的Git配置变量core.sparseCheckout，将其设置为true。

  $ git config core.sparseCheckout true
  

• 设置.git/info/sparse-checkout的内容，如下：

  $ printf "doc1\ndoc3\n" > .git/info/sparse-checkout
  $ cat .git/info/sparse-checkout
  doc1
  doc3
  

• 执行git checkout命令后，会发现工作区中doc2目录不见了。

  $ git checkout
  $ ls -F
  doc1/ doc3/
  

• 这时如果用git ls-files命令查看，会发现doc2目录下的文件被设置了skip-worktree标志。

  $ git ls-files -v
  H doc1/readme.txt
  S doc2/readme.txt
  H doc3/readme.txt
  

• 修改.git/info/sparse-checkout的内容，如下：

  $ printf "doc3\n" > .git/info/sparse-checkout
  $ cat .git/info/sparse-checkout
  doc3
  

• 执行git checkout命令后，会发现工作区中doc1目录也不见了。

  $ git checkout
  $ ls -F
  doc3/
  

• 这时如果用git ls-files命令查看，会发现doc1和doc2目录下的文件都被设置了skip-worktree标志。

  $ git ls-files -v
  S doc1/readme.txt
  S doc2/readme.txt
  H doc3/readme.txt
  

• 修改.git/info/sparse-checkout的内容，使之包含一个星号，即在工作区检出所有的内容。

  $ printf "*\n" > .git/info/sparse-checkout
  $ cat .git/info/sparse-checkout
  *
  

• 执行git checkout，会发现所有目录又都回来了。

  $ git checkout
  $ ls -F
  doc1/ doc2/ doc3/
  

文件.git/info/sparse-checkout的文件格式类似于.gitignore的格式，也支持用感叹号实现反向操作。例如不检出目录doc2下的文件，而检出其他文件，可以使用下面的语法（注意顺序不能写反）：

*
!doc2/

注意如果使用命令git checkout – <file>...，即不是切换分支而是用分支中的文件替换暂存区和工作区的话，则忽略skip-worktree标志。例如下面的操作中，虽然doc2被设置为不检出，但是执行git checkout .命令后，还是所有的目录都被检出了。

$ git checkout .
$ ls -F
doc1/ doc2/ doc3/
$ git ls-files -v
H doc1/readme.txt
S doc2/readme.txt
H doc3/readme.txt

如果修改doc2目录下的文件，或者在doc2目录下添加新文件，Git会视而不见。

$ echo hello >> doc2/readme.txt
$ git status
# On branch master
nothing to commit (working directory clean)

若此时通过取消core.sparseCheckout配置变量的设置而关闭稀疏检出，也不会改变目录doc2下的文件的skip-worktree标志。这种情况或者通过git update-index –no-skip-worktree – <file>...来更改index中对应文件的skip-worktree标志，或者重新启用稀疏检出更改相应文件的检出状态。

在克隆一个版本库时只希望检出部分文件或目录，可以在执行克隆操作的时候使用--no-checkout或-n参数，不进行工作区文件的检出。例如下面的操作从前面示例的sparse1版本库克隆到sparse2中，不进行工作区文件的检出。

$ git clone -n sparse1 sparse2
Cloning into sparse2...
done.

检出完成后可以发现sparse2的工作区是空的，而且版本库中也不存在index文件。如果执行git status命令会看到所有文件都被标识为删除。

$ cd sparse2
$ git status -s
D  doc1/readme.txt
D  doc2/readme.txt
D  doc3/readme.txt

如果希望通过稀疏检出的功能，只检出其中一个目录如doc2，可以用如下方法实现：

$ git config core.sparseCheckout true
$ printf "doc2\n" > .git/info/sparse-checkout
$ git checkout

之后看到工作区中检出了doc2目录，而其他文件被设置了skip-worktree标志。

$ ls -F
doc2/
$ git ls-files -v
S doc1/readme.txt
H doc2/readme.txt
S doc3/readme.txt

8.2.3.2. 浅克隆¶

上一节介绍的稀疏检出，可以部分检出版本库中的文件，但是版本库本身仍然包含所有的文件和历史。如果只对一个大的版本库的最近的部分历史提交感兴趣，而不想克隆整个版本库，稀疏检出是解决不了的，而是要采用本节介绍的浅克隆。

实现版本库的浅克隆的非常简单，只需要在执行git clone或者git fetch操作时用--depth <depth>参数设定要获取的历史提交的深度（<depth>大于0），就会把源版本库分支上最近的<depth> + 1个历史提交作为新版本库的全部历史提交。

通过浅克隆方式克隆出来的版本库，每一个提交的SHA1哈希值和源版本库的相同，包括提交的根节点也是如次，但是Git通过特殊的实现，使得浅克隆的根节点提交看起来没有父提交。正因为浅克隆的提交对象的SHA1哈希值和源版本库一致，所以浅克隆版本库可以执行git fetch或者git pull从源版本库获取新的提交。但是浅克隆版本库也存在着很多限制，如：

• 不能从浅克隆版本库克隆出新的版本库。
• 其他版本库不能从浅克隆获取提交。
• 其他版本库不能推送提交到浅克隆版本库。
• 不要从浅克隆版本库推送提交至其他版本库，除非确认推送的目标版本库包含浅克隆版本库中缺失的全部历史提交，否则会造成目标版本库包含不完整的提交历史导致版本库无法操作。
• 在浅克隆版本库中执行合并操作时，如果所合并的提交出现在浅克隆历史中，则可以顺利合并，否则会出现大量的冲突，就好像和无关的历史进行合并一样。

由于浅克隆包含上述限制，因此浅克隆一般用于对远程版本库的查看和研究，如果在浅克隆版本库中进行了提交，最好通过git format-patch命令导出为补丁文件再应用到远程版本库中。

下面的操作使用git clone命令创建一个浅克隆。注意：源版本库如果是本地版本库要使用file://协议，若直接接使用本地路径则不会实现浅克隆。

$ git clone --depth 2 file:///path/to/repos/hello-world.git shallow1

然后进入到本地克隆目录中，会看到当前分支上只有3个提交。

$ git log  --oneline
c4acab2 Translate for Chinese.
683448a Add I18N support.
d81896e Fix typo: -help to --help.

查看提交的根节点d81896e，则会看到该提交实际上也包含父提交。

$ git cat-file -p HEAD^^
tree f9d7f6b0af6f3fffa74eb995f1d781d3c4876b25
parent 10765a7ef46981a73d578466669f6e17b73ac7e3
author user1 <user1@sun.ossxp.com> 1294069736 +0800
committer user2 <user2@moon.ossxp.com> 1294591238 +0800

Fix typo: -help to --help.

而查看该提交的父提交，Git会报错。

$ git log 10765a7ef46981a73d578466669f6e17b73ac7e3
fatal: bad object 10765a7ef46981a73d578466669f6e17b73ac7e3

对于正常的Git版本库来说，如果对象库中一个提交丢失绝对是大问题，版本库不可能被正常使用。而浅克隆之所以看起来一切正常，是因为Git使用了类似嫁接（下一节即将介绍）的技术。

在浅克隆版本库中存在一个文件.git/shallow，这个文件中罗列了应该被视为提交根节点的提交SHA1哈希值。查看这个文件会看到提交d81896e正在其中：

$ cat .git/shallow
b56bb510a947651e4717b356587945151ac32166
d81896e60673771ef1873b27a33f52df75f70515
e64f3a216d346669b85807ffcfb23a21f9c5c187

列在.git/shallow文件中的提交会构建出对应的嫁接提交，使用类似嫁接文件.git/info/grafts（下节讨论）的机制，当Git访问这些对象时就好像这些对象是没有父提交的根节点一样。