українська мова ▾ 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 <tree>
--source=<дерево>

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

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

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

-p
--patch

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

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

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

--inter-hunk-context=<n>

Показує контекст між різницями (diff hanks), до вказаної <кількості> рядків, таким чином об’єднуючи ханки, що знаходяться близько один до одного. За замовчуванням використовується значення 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=<стиль>

Те саме, що й опція --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=<файл>

Специфікація шляху передається у <файл> замість аргументів командного рядка. Якщо <файл> дорівнює саме -, то використовується стандартний ввід. Елементи Pathspec розділяються символами LF або CR/LF. Елементи Pathspec можна брати в лапки, як пояснено для змінної конфігурації 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]