简体中文 ▾ Topics ▾ Latest version ▾ git-restore last updated in 2.54.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`恢复索引中的内容，或者用`--staged --worktree`同时恢复工作区和索引。

默认情况下，如果给了`--staged`，内容将从`HEAD`恢复，否则从索引恢复。使用`--source`来恢复不同的提交。

关于这三个命令的区别，见git[1]中的 "重置、恢复和还原"。

选项

-s <目录树>
--source=<目录树>

用给定树的内容恢复工作区的文件。通常是通过命名与之相关的提交、分支或标签来指定源树。

如果没有指定，如果给了`--staged`，则从`HEAD`恢复内容，否则从索引恢复。

作为一种特殊情况，如果 A 和 B 的合并库只有一个，则可以使用 "A...B "作为合并库的快捷方式。您最多可以省略 A 和 B 中的一个，在这种情况下，它默认为 HEAD。

-p
--patch

交互式地选择还原源和还原位置之间的差异中的猎物。参见 git-add[1] 的 '互动模式' 部分，了解如何操作 --patch 模式。

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

生成带有 <n> 行上下文的差异。上下文行数默认为 diff.context 或 3（如果未设置配置变量）。（由于历史原因，不带 <n> 的 -U 被默认接受为 -p 的同义词）。

--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 阶段（‘我们的’）或第 #3 阶段（‘他们的’）。 从工作区树（即使用 --source 选项）中检出路径时，不能使用该选项。

注意，在`git rebase`和`git pull --rebase`过程中，'我们的’和’他们的’可能会出现互换。详见 git-checkout[1] 中对相同选项的解释。

-m
--merge

从索引中恢复工作区树上的文件时，在未合并路径中重新创建冲突合并。 该选项不能用于从工作区树中检出路径（即使用 --source 选项）。

--conflict=<样式>

与上面的 --merge 选项相同，但改变了冲突块的显示方式，覆盖 merge.conflictStyle 配置变量。可能的值是 merge（默认）和 diff3（除了 merge 样式显示的内容外，还显示原始内容）。

--ignore-unmerged

当从索引中恢复工作区树上的文件时，如果有未合并的条目，并且没有指定 --ours、--theirs 、--merge 或 --conflict ，不要中止操作。工作区树上未合并的路径将被忽略。

--ignore-skip-worktree-bits

在稀疏检出模式下，默认情况下只更新由`<路径规范>和$GIT_DIR/info/sparse-checkout 中稀疏模式匹配的条目。这个选项忽略了稀疏模式，无条件地恢复了符合 `<路径规范> 中的任何文件。

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

如果`<pathspec>命名了一个活动的子模块，并且恢复的位置包括工作区，只有在给出这个选项的情况下，子模块才会被更新，在这种情况下，它的工作区将被恢复到超级项目中记录的提交，并且任何本地修改都会被覆盖。如果什么都不使用（或--no-recurse-submodules`），子模块的工作区将不会被更新。就像git-checkout[1]，这将分离子模块的`HEAD`。

--overlay
--no-overlay

在覆盖模式下，该命令在恢复时不会删除文件。在无覆盖模式下，不出现在 --source 树中的被追踪文件会被删除，以使它们与 <目录树> 完全匹配。默认是无覆盖模式。

--pathspec-from-file=<file>

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

--pathspec-file-nul

只有在使用 --pathspec-from-file 选项时才有意义。指定路径元素用 NUL 字符分隔，所有其他字符都按字面意思（包括换行符和引号）表示。

--

不将之后的参数解释为选项。

<路径规范>...

限制受操作影响的路径。

更多细节请参见 gitglossary[7] 中的 路径规范 条目。

实例

下面的序列切换到 "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] 文档