Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.51.1 no changes
-
2.51.0
2025-08-18
- 2.50.1 no changes
- 2.50.0 no changes
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.43.1 → 2.48.2 no changes
-
2.43.0
2023-11-20
- 2.35.1 → 2.42.4 no changes
-
2.35.0
2022-01-24
- 2.30.1 → 2.34.8 no changes
-
2.30.0
2020-12-27
- 2.27.1 → 2.29.3 no changes
-
2.27.0
2020-06-01
- 2.25.1 → 2.26.3 no changes
-
2.25.0
2020-01-13
- 2.23.1 → 2.24.4 no changes
-
2.23.0
2019-08-16
СИНОПСИС
gitrestore[<options>] [--source=<tree>] [--staged] [--worktree] [--] <pathspec>…gitrestore[<options>] [--source=<tree>] [--staged] [--worktree]--pathspec-from-file=<file> [--pathspec-file-nul]gitrestore(-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).Зверніть увагу, що під час виконання команд
gitrebaseтаgitpull--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)
-
взяти файл з іншого коміту
-
відновити
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
Частина набору git[1]