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

НАЗВА

git-reset - Скинути поточний HEAD до вказаного стану

СИНОПСИС

git reset [-q] [<tree-ish>] [--] <pathspec>…​
git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]
git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>…​]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]

ОПИС

У перших трьох формах скопіюйте записи з <tree-ish> до індексу. В останній формі встановіть поточний заголовок гілки (HEAD) на <commit>, за бажанням змінюючи індекс та робоче дерево відповідно. <tree-ish>/<commit> за замовчуванням має значення HEAD у всіх формах.

git reset [-q] [<tree-ish>] [--] <pathspec>...
git reset [-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]

Ці форми скидають записи індексу для всіх шляхів, що відповідають <специфікації шляху>, до їхнього стану за станом <приблизно-дерево>. (Це не впливає на робоче дерево чи поточну гілку.)

Це означає, що git reset <шлях> є протилежністю git add <шлях>. Ця команда еквівалентна git restore [--source=<деревоподібність>] --staged <шлях>....

Після запуску git reset <pathspec> для оновлення запису індексу, ви можете скористатися git-restore[1] для перевірки вмісту індексу до робочого дерева. Або ж, використовуючи git-restore[1] та вказавши коміт з --source, ви можете скопіювати вміст шляху з коміту до індексу та до робочого дерева одночасно.

git reset (--patch | -p) [<tree-ish>] [--] [<pathspec>...]

Інтерактивно вибирати фрагменти в різниці між індексом та <деревом-і-має> (за замовчуванням HEAD). Вибрані фрагменти застосовуються до індексу у зворотному порядку.

Це означає, що git reset -p є протилежністю git add -p, тобто ви можете використовувати його для вибіркового скидання ханків. Дивіться розділ "Інтерактивний режим" у git-add[1], щоб дізнатися, як працювати з режимом --patch.

git reset [<mode>] [<commit>]

Ця форма скидає поточну головку гілки до <commit> та, можливо, оновлює індекс (скидаючи його до дерева <commit>) та робочого дерева залежно від <mode>. Перед операцією ORIG_HEAD встановлюється на кінчик поточної гілки. Якщо <mode> пропущено, за замовчуванням використовується значення --mixed. <mode> має бути одним із наступних:

--soft

Зовсім не торкається індексного файлу чи робочого дерева (але скидає заголовок до <commit>, як це роблять усі режими). Це залишає всі ваші змінені файли "Зміни для коміту", як сказав би git status.

--mixed

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

Якщо вказано -N, видалені шляхи позначаються як такі, що мають бути додані (див. git-add[1]).

--hard

Скидає індекс та робоче дерево. Будь-які зміни до відстежуваних файлів у робочому дереві з моменту <commit> відкидаються. Будь-які невідстежувані файли або каталоги, що заважають запису будь-яких відстежуваних файлів, просто видаляються.

--merge

Скидає індекс та оновлює файли в робочому дереві, які відрізняються між <commit> та HEAD, але зберігає ті, що відрізняються між індексом та робочим деревом (тобто ті, до яких внесено зміни, що не були додані). Якщо файл, який відрізняється між <commit> та індексом, містить неіндексовані зміни, скидання переривається.

Іншими словами, --merge виконує щось на кшталт git read-tree -u -m <commit>, але переносить далі необ’єднані записи індексу.

--keep

Скидає записи індексу та оновлює файли в робочому дереві, які відрізняються між <commit> та HEAD. Якщо файл, який відрізняється між <commit> та HEAD, містить локальні зміни, скидання переривається.

--[no-]recurse-submodules

Коли робоче дерево оновлюється, використання --recurse-submodules також рекурсивно скине робоче дерево всіх активних підмодулів відповідно до коміту, записаного в суперпроекті, а також встановить HEAD підмодулів на відключення під час цього коміту.

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

ОПЦІЇ

-q
--quiet

Мовчи, повідомляй лише про помилки.

--refresh
--no-refresh

Оновити індекс після змішаного скидання. Увімкнено за замовчуванням.

--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, а всі інші символи (включно з символами нового рядка та лапками) сприймаються буквально.

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

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

--inter-hunk-context=<n>

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

--

Не інтерпретуйте жодних додаткових аргументів як варіанти.

<pathspec>...

Обмежує шляхи, на які впливає операція.

Для отримання додаткової інформації див. запис «pathspec» у gitglossary[7].

ПРИКЛАДИ

Скасувати додавання 
$ edit                                     (1)
$ git add frotz.c filfre.c
$ mailx                                    (2)
$ git reset                                (3)
$ git pull git://info.example.com/ nitfol  (4)

  1. Ви із задоволенням працюєте над чимось і бачите, що зміни в цих файлах у порядку. Ви не хочете бачити їх, коли запускаєте git diff, оскільки плануєте працювати над іншими файлами, а зміни в цих файлах відволікають.

  2. Хтось просить вас витягнути, і зміни звучать так, гідні об’єднання.

  3. Однак, ви вже забруднили індекс (тобто ваш індекс не відповідає коміту HEAD). Але ви знаєте, що вилучення, яке ви збираєтеся зробити, не впливає на frotz.c або filfre.c, тому ви скасуєте зміни індексу для цих двох файлів. Ваші зміни в робочому дереві залишаються там.

  4. Потім ви можете витягнути та об’єднати, залишивши зміни frotz.c та filfre.c у робочому дереві.

Скасувати коміт та повторити 
$ git commit ...
$ git reset --soft HEAD^      (1)
$ edit                        (2)
$ git commit -a -c ORIG_HEAD  (3)

  1. Найчастіше це трапляється, коли ви згадали, що щойно закомітований файл не завершений, або ви помилилися в повідомленні коміту, або й те, й інше. Залишає робоче дерево таким, яким воно було до "скидання".

  2. Внесіть виправлення до робочих файлів дерев.

  3. "reset" копіює старий заголовок до .git/ORIG_HEAD; повторіть коміт, починаючи з повідомлення журналу. Якщо вам не потрібно далі редагувати повідомлення, ви можете замість цього вказати опцію -C.

    Дивіться також опцію --amend для git-commit[1].

Скасувати коміт, зробивши його тематичною гілкою 
$ git branch topic/wip          (1)
$ git reset --hard HEAD~3       (2)
$ git switch topic/wip          (3)

  1. Ви зробили кілька комітів, але зрозуміли, що їх передчасно помістити в гілку master. Ви хочете продовжити їх полірування в тематичній гілці, тому створіть гілку topic/wip з поточної гілки HEAD.

  2. Перемотайте master-гілку назад, щоб позбутися цих трьох комітів.

  3. Перейдіть до гілки topic/wip та продовжуйте роботу.

Скасувати коміти назавжди 
$ git commit ...
$ git reset --hard HEAD~3   (1)

  1. Останні три коміти (HEAD, HEAD^ та HEAD~2) були поганими, і ви не хочете їх більше ніколи бачити. Не робіть цього, якщо ви вже передали ці коміти комусь іншому. (Див. розділ "ВІДНОВЛЕННЯ З ПЕРЕБАЗУВАННЯ ВИЩЕГО ПОТОКУ" в git-rebase[1], щоб дізнатися про наслідки цього.)

Скасувати об’єднання або витягування 
$ git pull                         (1)
Автоматичне об'єднання нітфолів
КОНФЛІКТ (контент): Конфлікт злиття в nitfol
Автоматичне злиття не вдалося; виправте конфлікти та зафіксуйте результат.
$ git reset --hard                 (2)
$ git pull . topic/branch          (3)
Оновлення з 41223... до 13134...
Перемотка вперед
$ git reset --hard ORIG_HEAD       (4)

  1. Спроба оновлення з основної платформи призвела до багатьох конфліктів; ви не були готові витрачати багато часу на злиття зараз, тому вирішили зробити це пізніше.

  2. "pull" не створив коміт злиття, тому git reset --hard, що є синонімом git reset --hard HEAD, очищає індексний файл та робоче дерево від безладу.

  3. Об’єднати тематичну гілку з поточною гілкою, що призвело до перемотування вперед.

  4. Але ви вирішили, що тематична гілка ще не готова для публічного використання. "pull" або "merge" завжди залишає оригінальну кінчик поточної гілки в ORIG_HEAD, тому скидання до нього повертає ваш індексний файл і робоче дерево до цього стану, а кінчик гілки скидається до цього коміту.

Скасувати злиття або витягування всередині непрацюючого дерева 
$ git pull                         (1)
Автоматичне об'єднання nitfol
Об'єднання, виконане рекурсивним способом.
 nitfol                |   20 +++++----
 ...
$ git reset --merge ORIG_HEAD      (2)

  1. Навіть якщо у вашому робочому дереві є локальні зміни, ви можете сміливо сказати git pull, коли знаєте, що зміни в іншій гілці не перетинаються з ними.

  2. Після перевірки результату злиття ви можете виявити, що зміни в іншій гілці незадовільні. Виконання команди git reset --hard ORIG_HEAD дозволить вам повернутися до попереднього стану, але призведе до відкидання ваших локальних змін, чого ви не хочете. Команда git reset --merge зберігає ваші локальні зміни.

Перерваний робочий процес

Припустімо, вас перериває терміновий запит на виправлення, поки ви працюєте над великою зміною. Файли у вашому робочому дереві ще не готові до фіксації, але вам потрібно перейти до іншої гілки для швидкого виправлення помилки.

$ git switch feature  ;# ви працювали у відділі "функціональні функції" та
$ work work work      ;# був перерваний
$ git commit -a -m "snapshot WIP"                 (1)
$ git switch master
$ fix fix fix
$ git commit ;# commit with real log
$ git switch feature
$ git reset --soft HEAD^ ;# повернутися до стану незавершеного (2)
$ git reset                                       (3)

  1. Цей коміт буде видалено, тому повідомлення журналу про викидання буде прийнятним.

  2. Це видаляє коміт «WIP» з історії комітів та встановлює ваше робоче дерево у стан безпосередньо перед створенням цього знімка.

  3. На цьому етапі файл індексу все ще містить усі зміни незавершеного процесу, які ви зафіксували як «знімок незавершеного процесу». Це оновлює індекс, показуючи ваші незавершені файли як незакомічені.

    Див. також git-stash[1].

Скинути один файл в індексі

Припустимо, ви додали файл до свого індексу, але пізніше вирішили, що не хочете додавати його до свого коміту. Ви можете видалити файл з індексу, зберігаючи зміни, за допомогою команди git reset.

$ git reset -- frotz.c                      (1)
$ git commit -m "Зафіксувати файли в індексі"     (2)
$ git add frotz.c                           (3)

  1. Це видаляє файл з індексу, зберігаючи його в робочому каталозі.

  2. Це закріплює всі інші зміни в індексі.

  3. Знову додає файл до індексу.

Зберегти зміни в робочому дереві, відкинувши деякі попередні коміти

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

$ git tag start
$ git switch -c branch1
$ edit
$ git commit ...                            (1)
$ edit
$ git switch -c branch2                     (2)
$ git reset --keep start                    (3)

  1. Це закріплює ваші перші редагування у branch1.

  2. В ідеальному світі ви могли б усвідомити, що попередній коміт не належить до нової теми, коли створювали та перемикалися на branch2 (тобто git switch -c branch2 start), але ніхто не ідеальний.

  3. Але ви можете скористатися reset --keep, щоб видалити небажаний коміт після переходу на branch2.

Розділити коміт на послідовність комітів

Припустимо, що ви створили багато логічно окремих змін і закомітили їх разом. Потім, пізніше, ви вирішуєте, що, можливо, краще пов’язати кожен логічний фрагмент з власним комітом. Ви можете використовувати git reset для перемотування історії без зміни вмісту ваших локальних файлів, а потім послідовно використовувати git add -p для інтерактивного вибору фрагментів для включення до кожного коміту, використовуючи git commit -c для попереднього заповнення повідомлення коміту.

$ git reset -N HEAD^                        (1)
$ git add -p                                (2)
$ git diff --cached                         (3)
$ git commit -c HEAD@{1}                    (4)
...                                         (5)
$ git add ...                               (6)
$ git diff --cached                         (7)
$ git commit ...                            (8)

  1. Спочатку скиньте історію на один коміт назад, щоб видалити оригінальний коміт, але залишити робоче дерево з усіма змінами. Параметр -N гарантує, що будь-які нові файли, додані за допомогою HEAD, все ще будуть позначені, щоб git add -p їх знайшов.

  2. Далі ми інтерактивно вибираємо ханки diff для додавання за допомогою функції git add -p. Ця команда запитає вас про кожен ханк diff по черзі, і ви можете використовувати прості команди, такі як «так, включити це», «Ні, не включати це» або навіть дуже потужну функцію «редагувати».

  3. Щойно ви визначитеся з потрібними вам частинами змін, перевірте, що було підготовлено для першого коміту, використовуючи git diff --cached. Це покаже всі зміни, які були переміщені до індексу та які ось-ось будуть закомічені.

  4. Далі закоміть зміни, що зберігаються в індексі. Опція -c вказує на попереднє заповнення повідомлення коміту з оригінального повідомлення, з якого ви почали в першому коміті. Це корисно, щоб уникнути його повторного введення. HEAD@{1} — це спеціальна нотація для коміту, на якому знаходився HEAD до оригінального коміту reset (1 зміна тому). Дивіться git-reflog[1] для отримання додаткової інформації. Ви також можете використовувати будь-яке інше дійсне посилання на коміт.

  5. Ви можете повторити кроки 2-4 кілька разів, щоб розбити вихідний код на будь-яку кількість комітів.

  6. Тепер ви розділили багато змін на окремі коміти та, можливо, більше не використовуєте режим патча команди git add для вибору всіх незбережених змін.

  7. Ще раз перевірте, чи ви включили те, що хотіли. Ви також можете переконатися, що git diff не показує жодних змін, які залишилися для подальшого коміту.

  8. І нарешті створіть фінальний коміт.

ОБГОВОРЕННЯ

У таблицях нижче показано, що відбувається під час запуску:

git reset --option target

щоб скинути значення HEAD до іншого коміту (target) з різними параметрами скидання залежно від стану файлів.

У цих таблицях A, B, C та D – це різні стани файлу. Наприклад, перший рядок першої таблиці означає, що якщо файл знаходиться у стані A у робочому дереві, у стані B в індексі, у стані C в HEAD та у стані D у цілі, то git reset --soft target залишить файл у робочому дереві у стані A, а в індексі – у стані B. Він скидає (тобто переміщує) HEAD (тобто кінчик поточної гілки, якщо ви на ній перебуваєте) до target (яка має файл у стані D).

робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 A       B     C    D     --soft   A       B     D
			  --mixed  A       D     D
			  --hard   D       D     D
			  --merge (заборонено)
			  --keep  (заборонено)
робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 A       B     C    C     --soft   A       B     C
			  --mixed  A       C     C
			  --hard   C       C     C
			  --merge (заборонено)
			  --keep   A       C     C
робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 B       B     C    D     --soft   B       B     D
			  --mixed  B       D     D
			  --hard   D       D     D
			  --merge  D       D     D
			  --keep  (заборонено)
робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 B       B     C    C     --soft   B       B     C
			  --mixed  B       C     C
			  --hard   C       C     C
			  --merge  C       C     C
			  --keep   B       C     C
робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 B       C     C    D     --soft   B       C     D
			  --mixed  B       D     D
			  --hard   D       D     D
			  --merge (заборонено)
			  --keep  (заборонено)
робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 B       C     C    C     --soft   B       C     C
			  --mixed  B       C     C
			  --hard   C       C     C
			  --merge  B       C     C
			  --keep   B       C     C

Опція git reset --merge призначена для використання під час скидання конфліктного злиття. Будь-яка операція злиття гарантує, що робочий файл дерева, який бере участь у злитті, не має локальних змін щодо індексу перед його початком, і що результат записується в робоче дерево. Отже, якщо ми бачимо певну різницю між індексом та цільовим об’єктом, а також між індексом та робочим деревом, це означає, що ми не скидаємо стан, який залишила операція злиття після невдалого конфлікту. Ось чому в цьому випадку ми забороняємо опцію --merge.

git reset --keep призначений для використання під час видалення деяких останніх комітів у поточній гілці, зберігаючи зміни в робочому дереві. Якщо можуть виникнути конфлікти між змінами в коміті, який ми хочемо видалити, та змінами в робочому дереві, яке ми хочемо зберегти, скидання заборонено. Ось чому воно заборонено, якщо є зміни як між робочим деревом та HEAD, так і між HEAD та цільовим деревом. Для безпеки воно також заборонено, коли є необ’єднані записи.

У наступних таблицях показано, що відбувається, коли є необ’єднані записи:

робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 X       U     A    B     --soft  (заборонено)
			  --mixed  X       B     B
			  --hard   B       B     B
			  --merge  B       B     B
			  --keep  (заборонено)
робочий індекс HEAD цільовий робочий індекс HEAD
----------------------------------------------------
 X       U     A    A     --soft  (заборонено)
			  --mixed  X       A     A
			  --hard   A       A     A
			  --merge  A       A     A
			  --keep  (заборонено)

X означає будь-який стан, а U означає необ’єднаний індекс.

GIT

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