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