设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
打补丁
调试
邮件
外部系统
服务器管理
指南
管理
底层命令
-
2.49.0
2025-03-14
- 2.43.1 → 2.48.1 无更改
-
2.43.0
2023-11-20
- 2.35.1 → 2.42.4 无更改
-
2.35.0
2022-01-24
- 2.30.1 → 2.34.8 无更改
-
2.30.0
2020-12-27
- 2.27.1 → 2.29.3 无更改
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 无更改
-
2.25.0
2020-01-13
- 2.23.1 → 2.24.4 无更改
-
2.23.0
2019-08-16
概要
git restore [<选项>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>… git restore [<选项>] [--source=<tree>] [--staged] [--worktree] --pathspec-from-file=<file> [--pathspec-file-nul] git restore (-p|--patch) [<选项>] [--source=<tree>] [--staged] [--worktree] [--] [<pathspec>…]
描述
使用恢复源中的一些内容恢复工作树中指定的路径。如果一个路径被跟踪,但不存在于恢复源中,它将被删除以匹配源。
该命令也可以用于使用 --staged
恢复索引中的内容,或者使用 --staged --worktree
同时恢复工作树和索引。
默认情况下,如果给定了 --staged
,则从 HEAD
恢复内容,否则从索引恢复。使用 --source
从不同的提交恢复。
请参阅 git[1] 中的 "Reset, restore and revert" 以了解这三个命令之间的区别。
此命令是实验性的。该行为可能会更改。
选项
-
-s <tree>
-
--source=<tree>
-
使用给定树中的内容恢复工作树文件。通常通过命名与源树关联的提交、分支或标签来指定源树。
如果未指定,则如果给定了
--staged
,则从HEAD
恢复内容,否则从索引恢复。作为特殊情况,您可以将
"<rev-A>...<rev-B>"
用作 <rev-A> 和 <rev-B> 的合并基础的快捷方式(如果只有一个合并基础)。您可以最多省略 <rev-A> 和 <rev-B> 中的一个,在这种情况下,它默认为HEAD
。 -
-p
-
--patch
-
交互式地选择恢复源和恢复位置之间差异中的 hunk。请参阅 git-add[1] 的 "Interactive Mode" 部分,了解如何操作
--patch
模式。请注意,
--patch
可以不接受任何 pathspec,并将提示恢复所有修改的路径。 -
-W
-
--worktree
-
-S
-
--staged
-
指定恢复位置。如果未指定任何选项,则默认情况下恢复工作树。指定
--staged
将仅恢复索引。同时指定两者将同时恢复两者。 -
-q
-
--quiet
-
安静,抑制反馈消息。隐含
--no-progress
。 -
--progress
-
--no-progress
-
默认情况下,当进度状态连接到终端时,会在标准错误流上报告进度状态,除非指定了
--quiet
。即使未连接到终端,此标志也会启用进度报告,而与--quiet
无关。 -
--ours
-
--theirs
-
当从索引中恢复工作树中的文件时,对于未合并的路径,请使用阶段 #2 (
ours
) 或 #3 (theirs
)。从 tree-ish 中检出路径时,不能使用此选项(即,使用--source
选项)。请注意,在
git rebase
和git pull --rebase
期间,ours
和theirs
可能会互换显示。有关详细信息,请参阅 git-checkout[1] 中相同选项的说明。 -
-m
-
--merge
-
当从索引中恢复工作树上的文件时,在未合并的路径中重新创建冲突的合并。从 tree-ish 中检出路径时,不能使用此选项(即,使用
--source
选项)。 -
--conflict=<style>
-
与上面的
--merge
选项相同,但更改了冲突的 hunk 的呈现方式,从而覆盖了merge.conflictStyle
配置变量。可能的值为merge
(默认)、diff3
和zdiff3
。 -
--ignore-unmerged
-
当从索引中恢复工作树上的文件时,如果存在未合并的条目,并且未指定
--ours
、--theirs
、--merge
或--conflict
,则不要中止操作。工作树上未合并的路径将被忽略。 -
--ignore-skip-worktree-bits
-
在稀疏检出模式下,默认设置是仅更新 <pathspec> 和
$GIT_DIR/info/sparse-checkout
中的稀疏模式匹配的条目。此选项忽略稀疏模式并无条件恢复 <pathspec> 中的任何文件。 -
--recurse-submodules
-
--no-recurse-submodules
-
如果 <pathspec> 命名了一个活动子模块,并且恢复位置包括工作树,则只有在给定此选项的情况下才会更新子模块,在这种情况下,其工作树将恢复为超项目中记录的提交,并且任何本地修改都将被覆盖。如果未使用任何内容(或
--no-recurse-submodules
),则不会更新子模块工作树。就像 git-checkout[1] 一样,这将分离子模块的HEAD
。 -
--overlay
-
--no-overlay
-
在 overlay 模式下,恢复时永远不要删除文件。在 no-overlay 模式下,删除未出现在
--source=<tree>
的 <tree> 中的跟踪文件,以使它们与 <tree> 完全匹配。默认值为 no-overlay 模式。 -
--pathspec-from-file=<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
有意义。Pathspec 元素用 NUL 字符分隔,所有其他字符都按字面意思理解(包括换行符和引号)。 -
--
-
不要将任何其他参数解释为选项。
-
<pathspec>...
-
限制受操作影响的路径。
有关更多详细信息,请参阅 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)
-
从另一个提交中取出一个文件
-
从索引中恢复
hello.c
如果您想恢复所有 C 源文件以匹配索引中的版本,您可以说
$ git restore '*.c'
请注意 *.c
周围的引号。文件 hello.c
也将被恢复,即使它不再位于工作树中,因为文件 globbing 用于匹配索引中的条目(而不是 shell 中的工作树)。
要恢复当前目录中的所有文件
$ git restore .
或者要恢复所有工作树文件,使用 *top* pathspec 魔术(请参阅 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
属于 git[1] 套件的一部分