1git-restore(1) 2============== 3 4NAME 5---- 6git-restore - Restore working tree files 7 8SYNOPSIS 9-------- 10[verse] 11'git restore' [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>... 12'git restore' (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [<pathspec>...] 13 14DESCRIPTION 15----------- 16Restore specified paths in the working tree with some contents from a 17restore source. If a path is tracked but does not exist in the restore 18source, it will be removed to match the source. 19 20The command can also be used to restore the content in the index with 21`--staged`, or restore both the working tree and the index with 22`--staged --worktree`. 23 24By default, the restore sources for working tree and the index are the 25index and `HEAD` respectively. `--source` could be used to specify a 26commit as the restore source. 27 28See "Reset, restore and revert" in linkgit:git[1] for the differences 29between the three commands. 30 31THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE. 32 33OPTIONS 34------- 35-s <tree>:: 36--source=<tree>:: 37 Restore the working tree files with the content from the given 38 tree. It is common to specify the source tree by naming a 39 commit, branch or tag associated with it. 40+ 41If not specified, the default restore source for the working tree is 42the index, and the default restore source for the index index is 43`HEAD`. When both `--staged` and `--worktree` are specified, 44`--source` must also be specified. 45 46-p:: 47--patch:: 48 Interactively select hunks in the difference between the 49 restore source and the restore location. See the ``Interactive 50 Mode'' section of linkgit:git-add[1] to learn how to operate 51 the `--patch` mode. 52+ 53Note that `--patch` can accept no pathspec and will prompt to restore 54all modified paths. 55 56-W:: 57--worktree:: 58-S:: 59--staged:: 60 Specify the restore location. If neither option is specified, 61 by default the working tree is restored. Specifying `--staged` 62 will only restore the index. Specifying both restores both. 63 64-q:: 65--quiet:: 66 Quiet, suppress feedback messages. Implies `--no-progress`. 67 68--progress:: 69--no-progress:: 70 Progress status is reported on the standard error stream 71 by default when it is attached to a terminal, unless `--quiet` 72 is specified. This flag enables progress reporting even if not 73 attached to a terminal, regardless of `--quiet`. 74 75--ours:: 76--theirs:: 77 When restoring files in the working tree from the index, use 78 stage #2 ('ours') or #3 ('theirs') for unmerged paths. 79+ 80Note that during `git rebase` and `git pull --rebase`, 'ours' and 81'theirs' may appear swapped. See the explanation of the same options 82in linkgit:git-checkout[1] for details. 83 84-m:: 85--merge:: 86 When restoring files on the working tree from the index, 87 recreate the conflicted merge in the unmerged paths. 88 89--conflict=<style>:: 90 The same as `--merge` option above, but changes the way the 91 conflicting hunks are presented, overriding the 92 `merge.conflictStyle` configuration variable. Possible values 93 are "merge" (default) and "diff3" (in addition to what is 94 shown by "merge" style, shows the original contents). 95 96--ignore-unmerged:: 97 When restoring files on the working tree from the index, do 98 not abort the operation if there are unmerged entries and 99 neither `--ours`, `--theirs`, `--merge` or `--conflict` is 100 specified. Unmerged paths on the working tree are left alone. 101 102--ignore-skip-worktree-bits:: 103 In sparse checkout mode, by default is to only update entries 104 matched by `<pathspec>` and sparse patterns in 105 $GIT_DIR/info/sparse-checkout. This option ignores the sparse 106 patterns and unconditionally restores any files in 107 `<pathspec>`. 108 109--overlay:: 110--no-overlay:: 111 In overlay mode, the command never removes files when 112 restoring. In no-overlay mode, tracked files that do not 113 appear in the `--source` tree are removed, to make them match 114 `<tree>` exactly. The default is no-overlay mode. 115 116EXAMPLES 117-------- 118 119The following sequence switches to the `master` branch, reverts the 120`Makefile` to two revisions back, deletes hello.c by mistake, and gets 121it back from the index. 122 123------------ 124$ git switch master 125$ git restore --source master~2 Makefile <1> 126$ rm -f hello.c 127$ git restore hello.c <2> 128------------ 129 130<1> take a file out of another commit 131<2> restore hello.c from the index 132 133If you want to restore _all_ C source files to match the version in 134the index, you can say 135 136------------ 137$ git restore '*.c' 138------------ 139 140Note the quotes around `*.c`. The file `hello.c` will also be 141restored, even though it is no longer in the working tree, because the 142file globbing is used to match entries in the index (not in the 143working tree by the shell). 144 145To restore all files in the current directory 146 147------------ 148$ git restore . 149------------ 150 151or to restore all working tree files with 'top' pathspec magic (see 152linkgit:gitglossary[7]) 153 154------------ 155$ git restore :/ 156------------ 157 158To restore a file in the index to match the version in `HEAD` (this is 159the same as using linkgit:git-reset[1]) 160 161------------ 162$ git restore --staged hello.c 163------------ 164 165or you can restore both the index and the working tree (this the same 166as using linkgit:git-checkout[1]) 167 168------------ 169$ git restore --source=HEAD --staged --worktree hello.c 170------------ 171 172or the short form which is more practical but less readable: 173 174------------ 175$ git restore -s@ -SW hello.c 176------------ 177 178SEE ALSO 179-------- 180linkgit:git-checkout[1], 181linkgit:git-reset[1] 182 183GIT 184--- 185Part of the linkgit:git[1] suite