简体中文 ▾ 主题 ▾ 最新版本 ▾ git-restore 最后更新于 2.51.0

名称

git-restore - 恢复工作区文件

概要

git restore [<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>…​
git restore [<options>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul]
git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>…​]

描述

使用来自恢复源的内容，恢复工作区中指定的路径。如果某个路径已被追踪但在恢复源中不存在，它将被删除以与源保持一致。

该命令还可以通过 --staged 参数恢复暂存区（index）的内容，或者通过 --staged --worktree 同时恢复工作区和暂存区。

默认情况下，如果指定了 --staged，内容将从 HEAD 恢复，否则从暂存区恢复。使用 --source 可以从不同的提交进行恢复。

有关这三个命令之间的区别，请参阅 git[1] 中的“Reset、restore 和 revert”部分。

选项

-s <树>
--source=<树>

使用指定树对象的内容恢复工作区文件。通常通过指明与之关联的提交、分支或标签来指定源树。

如果未指定，当给定 --staged 时，内容从 HEAD 恢复，否则从暂存区恢复。

作为特殊情况，如果恰好有一个合并基准，你可以使用 "<修订版本-A>...<修订版本-B>" 作为 <修订版本-A> 和 <修订版本-B> 合并基准的快捷方式。你最多可以省略 <修订版本-A> 和 <修订版本-B> 中的一个，在这种情况下，它默认为 HEAD。

-p
--patch

在恢复源和恢复位置之间的差异中交互式地选择数据块（hunks）。请参阅 git-add[1] 的“交互模式”部分，了解如何操作 --patch 模式。

-U<n>
--unified=<n>

生成具有 <n> 行上下文的 diff。如果配置选项未设置，则默认为 diff.context 或 3。

--inter-hunk-context=<n>

在差异块之间显示上下文，最多达指定行数 <number>，从而合并彼此接近的块。默认为 diff.interHunkContext，如果未设置配置选项则为 0。

-W
--worktree
-S
--staged

指定恢复位置。如果两个选项都未指定，默认恢复工作区。指定 --staged 将仅恢复暂存区。两者都指定则同时恢复两者。

-q
--quiet

静默模式，不显示反馈消息。暗示了 --no-progress。

--progress
--no-progress

默认情况下，如果进度状态流被连接到终端，则进度状态会显示在标准错误流上，除非指定了 --quiet。此标志即使未连接到终端也会启用进度报告，无论 --quiet 如何。

--ours
--theirs

从暂存区恢复工作区文件时，对未合并的路径使用阶段 #2 (ours) 或 #3 (theirs)。从树对象检出路径（即使用 --source 选项）时不能使用此选项。

注意，在执行 git rebase 和 git pull --rebase 期间，ours 和 theirs 可能会显示为互换。有关详细信息，请参阅 git-checkout[1] 中相同选项的说明。

-m
--merge

从暂存区恢复工作区文件时，在未合并的路径中重新创建冲突合并。从树对象检出路径（即使用 --source 选项）时不能使用此选项。

--conflict=<风格>

与上面的 --merge 选项相同，但会更改冲突块的呈现方式，覆盖 merge.conflictStyle 配置变量。可能的值包括 merge（默认）、diff3 和 zdiff3。

--ignore-unmerged

从暂存区恢复工作区文件时，如果存在未合并的条目且未指定 --ours、--theirs、--merge 或 --conflict，则不要中止操作。工作区中未合并的路径将保持不变。

--ignore-skip-worktree-bits

在稀疏检出模式下，默认仅更新与 <路径规范> 和 $GIT_DIR/info/sparse-checkout 中的稀疏模式匹配的条目。此选项忽略稀疏模式，并无条件恢复 <路径规范> 中的任何文件。

--recurse-submodules
--no-recurse-submodules

如果 <路径规范> 命名了一个活动的子模块，且恢复位置包含工作区，则仅在给出此选项时才会更新该子模块，在这种情况下，其工作区将恢复到主项目中记录的提交，并覆盖任何本地修改。如果未使用任何参数（或使用 --no-recurse-submodules），子模块的工作区将不会更新。与 git-checkout[1] 一样，这会使子模块的 HEAD 处于分离状态。

--overlay
--no-overlay

在覆盖模式（overlay）下，恢复时从不删除文件。在非覆盖模式下，删除不在 --source=<树> 指定的 <树> 中的已追踪文件，使它们与 <树> 完全匹配。默认为非覆盖模式。

--pathspec-from-file=<文件>

Pathspec 从 <file> 而不是命令行参数传递。如果 <file> 是 -，则使用标准输入。Pathspec 元素由 LF 或 CR/LF 分隔。Pathspec 元素可以按 core.quotePath 配置变量的解释进行引用（参见 git-config[1]）。另请参见 --pathspec-file-nul 和全局 --literal-pathspecs。

--pathspec-file-nul

仅在与 --pathspec-from-file 一起使用时有意义。路径规范元素由 NUL 字符分隔，所有其他字符都被视为字面值（包括换行符和引号）。

--

不再将任何后续参数解释为选项。

<路径规范>...

限制受操作影响的路径。

有关更多详细信息，请参阅 gitglossary[7] 中的 pathspec 条目。

示例

以下序列切换到 master 分支，将 Makefile 还原到两个版本前，误删了 hello.c，然后从暂存区找回它。

$ git switch master
$ git restore --source master~2 Makefile  (1)
$ rm -f hello.c
$ git restore hello.c                     (2)

  1. 从另一个提交中取出一个文件

  2. 从暂存区恢复 hello.c

如果你想恢复 *所有* C 源文件以匹配暂存区中的版本，你可以执行

$ git restore '*.c'

注意 *.c 周围的引号。即使 hello.c 不再位于工作区中，它也将被恢复，因为文件通配符（globbing）被用于匹配暂存区中的条目（而不是由 shell 匹配工作区中的文件）。

恢复当前目录下的所有文件

$ git restore .

或使用 *顶级（top）* 路径规范魔法恢复所有工作区文件（参见 gitglossary[7]）

$ git restore :/

恢复暂存区中的一个文件以匹配 HEAD 中的版本（这与使用 git-reset[1] 相同）

$ git restore --staged hello.c

或者你可以同时恢复暂存区和工作区（这与使用 git-checkout[1] 相同）

$ git restore --source=HEAD --staged --worktree hello.c

或者更实用但可读性较差的简写形式

$ git restore -s@ -SW hello.c

另请参阅

git-checkout[1], git-reset[1]

GIT

Git[1] 套件的一部分