українська мова ▾ Topics ▾ Latest version ▾ git-restore last updated in 2.51.0

НАЗВА

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 для відновлення з іншого коміту.

Дивіться розділ «Скидання, відновлення та повернення до початкового стану» в git[1], щоб ознайомитися з відмінностями між цими трьома командами.

ОПЦІЇ

-s <дерево>
--source=<дерево>

Відновлює файли робочого дерева вмістом з вказаного дерева. Зазвичай початкове дерево вказується іменем коміту, гілки або тегу, повʼязаного з ним.

Якщо не вказано, вміст відновлюється з HEAD, якщо вказано --staged, інакше з індексу.

Як окремий випадок, ви можете використовувати "<rev-A>...<rev-B>" як скорочення для бази злиття <rev-A> та <rev-B>, якщо існує лише одна база злиття. Ви можете пропустити щонайбільше одну з <rev-A> та <rev-B>, і в цьому випадку зазвичай використовується HEAD.

-p
--patch

Команда дозволяє в інтерактивному режимі вибирати фрагменти у відмінностях (diff) між джерелом відновлення та місцем відновлення. Дивіться розділ «Інтерактивний режим» у git-add[1], щоб дізнатися, як керувати режимом --patch.

-U<n>
--unified=<n>

Створює файли відмінностей (diff) з <n> рядками контексту. Стандартно використовується diff.context або 3, якщо параметр конфігурації не встановлено.

--inter-hunk-context=<n>

Показує контекст між фрагментами відмінностей (diff hunks), до вказаної <кількості> рядків, таким чином обʼєднуючи фрагменти, що знаходяться близько один до одного. Стандартно використовується значення diff.interHunkContext або 0, якщо параметр конфігурації не встановлено.

-W
--worktree
-S
--staged

Визначає місце відновлення. Якщо не вказано жодного з параметрів, зазвичай відновлюється робоче дерево. Вказання --staged відновить лише індекс. Вказання обох параметрів відновить обидва.

-q
--quiet

Виводу немає, повідомлення зворотного звʼязку відкидаються. Мається на увазі --no-progress.

--progress
--no-progress

Повідомлення про стан виконання зазвичай зʼявляються у стандартному потоці помилок, коли він підключений до термінала, якщо не вказано --quiet. Цей прапорець дозволяє повідомляти про хід виконання, навіть якщо він не підключений до термінала, незалежно від --quiet.

--ours
--theirs

Під час відновлення файлів у робочому дереві з індексу використовуйте stage #2 (ours) або #3 (theirs) для необʼєднаних шляхів. Цей параметр не можна використовувати під час перевірки шляхів з деревоподібної структури (тобто з параметром --source).

Зверніть увагу, що під час виконання команд git rebase та git pull --rebase, ours та theirs можуть помінятися місцями. Дивіться пояснення цих самих опцій у git-checkout[1] для отримання детальної інформації.

-m
--merge

Під час відновлення файлів у робочому дереві з індексу, відтворює конфліктне злиття у необʼєднаних шляхах. Цей параметр не можна використовувати під час перевірки шляхів з деревоподібного елемента (тобто з параметром --source).

--conflict=<стиль>

Те саме, що й опція --merge вище, але змінює спосіб представлення фрагментів з конфліктами, перевизначаючи змінну конфігурації merge.conflictStyle. Можливі значення: merge (стандартно), diff3 та zdiff3.

--ignore-unmerged

Під час відновлення файлів в робочому дереві з індексу не переривати виконання, якщо є необʼєднані записи, і не вказано ні --ours, --theirs, --merge, --conflict. Необ’єднані шляхи в робочому дереві залишаються без змін.

--ignore-skip-worktree-bits

У режимі вибіркового перемикання зазвичай оновлюються лише записи, що відповідають <специфікатору-шляху> та вибірковим шаблонам у $GIT_DIR/info/sparse-checkout. Цей параметр ігнорує вибіркові шаблони та безумовно відновлює будь-які файли в <специфікаторі-шляху>.

--recurse-submodules
--no-recurse-submodules

Якщо <специфікатор-шляху> вказує на активний субмодуль, а місце відновлення містить робоче дерево, субмодуль буде оновлено лише за наявності цієї опції, і в цьому випадку його робоче дерево буде відновлено до коміту, записаного в суперпроєкті, а будь-які локальні зміни будуть перезаписані. Якщо нічого не використовується (або --no-recurse-submodules), робочі дерева субмодулів не будуть оновлені. Так само як і git-checkout[1], це від’єднає HEAD субмодуля.

--overlay
--no-overlay

У режимі накладання ніколи не видаляти файли під час відновлення. У режимі без накладання видаляти відстежувані файли, які не відображаються в <tree> --source=<tree>, щоб вони точно відповідали <tree>. Зазвичай використовується режим без накладання.

--pathspec-from-file=<файл>

Специфікатор шляху передається у <файл> замість аргументів командного рядка. Якщо <файл> дорівнює -, то використовується стандартний ввід. Елементи специфікатора шляху розділяються символами LF або CR/LF. Елементи специфікатора шляху можна брати в лапки, як це пояснено для змінної конфігурації core.quotePath (див. git-config[1]). Див. також --pathspec-file-nul та глобальну змінну --literal-pathspecs.

--pathspec-file-nul

Має сенс лише з --pathspec-from-file. Елементи Pathspec розділяються символом 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)

  1. взяти файл з іншого коміту

  2. відновити hello.c з індексу

Якщо ви хочете відновити всі сирцеві файли на 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]

GIT

Частина набору git[1]