checkout
根据当前的 工作区 中的 dvc.lock 和 .dvc 文件，更新由 DVC 跟踪的文件和目录。
概要
usage: dvc checkout [-h] [-q | -v] [--summary] [-d] [-R] [-f]
[--relink] [--allow-missing]
[targets [targets ...]]
positional arguments:
targets Limit command scope to these tracked files/directories,
.dvc files, or stage names.描述
此命令通常在执行 git checkout、git clone 或任何其他更改了 项目 中当前 dvc.lock 或 .dvc 文件的操作后使用。它会从 缓存 中恢复所有被 DVC 跟踪的数据文件和目录到工作区中的对应版本。
提供给该命令的 targets（如果有的话）将限制需要检出的内容。它可以接受被跟踪的文件或目录路径（包括被跟踪目录内的路径）、.dvc 文件以及阶段名称（在 dvc.yaml 中定义）。
执行 dvc checkout 时会进行以下操作：
-
检查
dvc.lock和.dvc文件，将其 输出项 的哈希值与 工作区 中实际的文件或目录进行比较（类似于dvc status的行为）。 -
缺失的数据文件或目录将从缓存中恢复；与
dvc.lock或.dvc文件不匹配的文件将被删除。参见选项--force和--relink。命令会打印出所做的更改列表。
💡 为方便起见，可使用 Git 钩子在 git checkout 后自动运行 dvc checkout。详见下方的 自动化示例 或 dvc install 了解更多细节。
默认情况下，此命令会尽量避免在工作区中复制缓存文件，而是在文件系统支持时使用 reflink（请参考 文件链接类型）。但下一个默认的链接策略是 copy，因此除非在 cache.type 中手动配置了其他文件链接类型，否则文件将被复制。请注意，除非项目使用非常大的数据（数 GB 或更多），否则文件副本通常不会造成显著负面影响。但对于大文件而言，使用文件链接至关重要——例如，复制一个 50GB 的文件可能需要几分钟，而使用链接则几乎可以瞬间完成任意大小文件的恢复。
当链接文件耗时超过预期（单个文件超过 10 秒）且未设置
cache.type时，系统将显示警告，提醒用户存在更快的链接类型可用。可通过使用dvc config cache将cache.slow_link_warning配置项设为false来关闭这些警告。
如果缓存中缺少某些文件，此命令将无法成功检出这些文件。在这种情况下，dvc checkout 会打印警告信息，并列出已部分完成的检出进度。
根据具体情况，有两种方法可以恢复缓存中缺失的文件。在某些情况下，可以使用 远程存储 中的数据，通过 dvc pull 命令拉取。在其他情况下，则必须通过 流水线 重新生成（使用 dvc repro）来重建其输出。
选项
-
--summary- 显示此命令在工作区中更改的简要摘要，而不是完整的更改列表。 -
-d,--with-deps- 仅在指定targets时有意义。它通过解析目标阶段或.dvc文件的所有依赖项来确定需要更新的文件：DVC 从相应流水线中的目标节点向后搜索。这不会检出比targets更晚阶段中引用的文件。 -
-R,--recursive- 通过在每个目标目录及其子目录中搜索dvc.lock和.dvc文件来确定要检出的文件。如果targets中没有目录，则此选项无效。 -
-f,--force- 删除工作区文件时不再提示确认。使用git checkout更改当前 DVC 文件集合可能导致 DVC 需要删除与引用不匹配或缓存中缺失的文件。（在 DVC 术语中，这些文件尚未“提交”。） -
--relink- 确保工作区中所有数据的文件链接策略（reflink、hardlink、symlink或copy）与项目设置的cache.type保持一致。实现方式是恢复当前 DVC 文件中引用的所有数据文件或目录（无论这些文件/目录是否已存在）。 -
--allow-missing- 即使某些文件或目录缺失，也允许命令执行成功。 -
-h,--help- 显示帮助信息并退出。 -
-q,--quiet- 不向标准输出写入任何内容。如果没有问题则以 0 退出，否则以 1 退出。 -
-v,--verbose- 显示执行dvc pull命令时的详细跟踪信息。
示例
让我们使用一个包含一些数据、代码、机器学习模型和流水线阶段的简单 工作区，例如为 快速入门 创建的 DVC 项目。然后我们可以观察在不同标签之间切换时，git checkout 和 dvc checkout 的行为变化。
工作区结构如下：
.
├── data
│ └── data.xml.dvc
├── dvc.lock
├── dvc.yaml
├── params.yaml
├── prc.json
├── scores.json
└── src
└── <code files here>请注意，该仓库包含以下标签，代表了最终模型的不同变体：
$ git tag
...
baseline-experiment <- First simple version of the model
bigrams-experiment <- Uses bigrams to improve the model现在我们可以运行 dvc checkout 来更新最新的 model.pkl、data.xml 以及任何其他由 DVC 跟踪的文件。model.pkl 文件的哈希值（ab349c2...）保存在 dvc.lock 中，可通过以下命令验证：
$ dvc checkout
$ md5 model.pkl
MD5 (data.xml) = ab349c2b5fa2a0f66d6f33f94424aebe示例：切换版本
如果我们想“回溯历史”该怎么办？git checkout 命令允许我们恢复仓库历史中的任意提交（包括标签）。它会自动调整仓库文件，必要时进行替换、添加或删除。
$ git checkout baseline-experiment # Git commit where model was created现在让我们检查 dvc.lock 中 model.pkl 的哈希值：
outs:
- path: model.pkl
md5: 98af33933679a75c2a51b953d3ab50aa但如果你查看 model.pkl 的 MD5，文件哈希仍然相同（ab349c2...）。这是因为 git checkout 只修改了 dvc.lock 和其他 DVC 文件，而对 model.pkl 或任何其他由 DVC 跟踪的文件/目录并未做任何操作。由于 Git 并不跟踪这些文件，我们需要执行以下命令来获取它们：
$ dvc checkout
M model.pkl
M data\features\
$ md5 model.pkl
MD5 (model.pkl) = 98af33933679a75c2a51b953d3ab50aaDVC 遍历了 dvc.yaml 中的各个阶段，并调整当前的 输出，使其与对应的 dvc.lock 文件中的 outs 保持一致。
示例：指定具体文件或目录
dvc checkout 仅影响与指定 targets 对应的被跟踪数据：
$ git checkout master
$ dvc checkout # Start with latest version of everything.
$ git checkout baseline-experiment -- dvc.lock
$ dvc checkout model.pkl # Get previous model file only.请注意，你可以在被跟踪的目录内检出特定数据。例如，featurize 阶段将整个 data/features 目录作为输出，但我们也可以只获取其中的部分内容：
$ dvc checkout data/features/test.pkl示例：自动化 DVC checkout
我们希望由 DVC 管理的数据文件或目录能与由 Git 管理的其他文件（如源代码）保持一致。这要求我们在执行 git checkout 后记得运行 dvc checkout，但我们并不总能记住这一点。如果这个过程可以自动化，那不是很好吗？
$ dvc installdvc install 可以安装 Git 钩子，用于自动化常见操作，包括在需要时自动运行 dvc checkout。
（在完成前述示例后），我们现在可以再次切换回 master 分支：
$ git checkout bigrams-experiment # Has the latest model version
$ md5 model.pkl
MD5 (model.pkl) = ab349c2b5fa2a0f66d6f33f94424aebe以前这需要两条命令：git checkout 后跟 dvc checkout。现在我们可以省略第二条命令，它会自动为我们执行。工作区文件也会相应地自动更新。