设置和配置
获取和创建项目
基本快照
分支与合并
共享和更新项目
检查和比较
打补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
底层命令
- 2.50.1 无更改
- 2.50.0 无变更
- 2.49.1 无更改
-
2.49.0
2025-03-14
- 2.43.1 → 2.48.2 无变更
-
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
[<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] 中的“Reset、restore 和 revert”部分。
此命令是实验性的。其行为可能会发生变化。
选项
-s
<tree>--source=
<tree>-
使用给定树中的内容恢复工作区文件。通常通过命名与其关联的提交、分支或标签来指定源树。
如果未指定,如果给出
--staged
,内容将从HEAD
恢复;否则,从索引恢复。作为特例,如果存在且仅存在一个合并基点,则可以使用
"
<rev-A>...
<rev-B>"
作为 <rev-A> 和 <rev-B> 合并基点的快捷方式。您最多可以省略 <rev-A> 和 <rev-B> 中的一个,在这种情况下它默认为HEAD
。 -p
--patch
-
交互式选择恢复源和恢复位置之间的差异中的代码块。参阅 git-add[1] 的“交互模式”一节,了解如何操作
--patch
模式。 -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=
<style>-
与上述
--merge
选项相同,但改变了冲突代码块的呈现方式,覆盖了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
-
在覆盖模式下,恢复时从不删除文件。在非覆盖模式下,删除未出现在
--source=
<tree> 的 <tree> 中的已跟踪文件,使它们精确匹配 <tree>。默认是非覆盖模式。 --pathspec-from-file=
<file>-
路径规范通过 <file> 传递而不是命令行参数。如果 <file> 恰好是
-
,则使用标准输入。路径规范元素通过 LF 或 CR/LF 分隔。路径规范元素可以像配置变量core.quotePath
所解释的那样进行引用(参阅 git-config[1])。另请参阅--pathspec-file-nul
和全局--literal-pathspecs
。 --pathspec-file-nul
-
仅在与
--pathspec-from-file
一起使用时有意义。路径规范元素由 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
不再在工作区中,它也会被恢复,因为文件通配符用于匹配索引中的条目(而不是由 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