git-restore

Название

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, чтобы восстановить содержимое из другого коммита.

Различия между этими тремя командами см. в разделе «Reset, restore and revert» справки git[1].

Параметры

-s <tree>

--source=<tree>

Восстановить файлы рабочего дерева, используя содержимое указанного дерева. В качестве исходного дерева обычно указывают связанный с ним коммит, ветку или тег.

Если не указано иное, содержимое восстанавливается из HEAD, если задано --staged, в противном случае — из индекса.

В особом случае в качестве сокращения для базового коммита слияния <rev-A> и <rev-B> можно использовать "<rev-A>...<rev-B>", если существует ровно один базовый коммит слияния. Можно опустить не более одного из аргументов <rev-A> и <rev-B>; в этом случае по умолчанию используется HEAD.

-p

--patch

Интерактивно выбрать фрагменты различий между источником восстановления и местом восстановления. О том, как работать в режиме --patch, см. раздел «Интерактивный режим» справки git-add[1].

-U<n>

--unified=<n>

Создавать различия с <n> строками контекста. Число строк контекста по умолчанию равно diff.context или 3, если переменная конфигурации не задана. (Из-за исторической случайности -U без <n> принимается без предупреждения как синоним -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 (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

В режиме наложения файлы при восстановлении никогда не удаляются. В режиме без наложения удаляются отслеживаемые файлы, отсутствующие в <tree> из --source=<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>...

Ограничивает пути, затрагиваемые операцией.

Подробнее см. статью pathspec в 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)

взять файл из другого коммита
восстановить hello.c из индекса

Чтобы восстановить all исходных файлов C в соответствии с версией из индекса, выполните команду

$ git restore '*.c'

Обратите внимание на кавычки вокруг *.c. Файл hello.c также будет восстановлен, хотя его уже нет в рабочем дереве, поскольку шаблон файла используется для поиска записей в индексе (а не в рабочем дереве оболочкой).

Чтобы восстановить все файлы в текущем каталоге

$ git restore .

или восстановить все файлы рабочего дерева с помощью магии pathspec 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]

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-restore