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
2025-06-16
- 2.39.4 → 2.49.1 no changes
-
2.39.3
2023-04-17
- 2.36.1 → 2.39.2 no changes
-
2.36.0
2022-04-18
- 2.34.1 → 2.35.8 no changes
-
2.34.0
2021-11-15
- 2.27.1 → 2.33.8 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
- 2.22.1 → 2.22.5 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.15.4 → 2.19.6 no changes
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
- 2.1.4 → 2.11.4 no changes
-
2.0.5
2014-12-17
СИНОПСИС
gitreset[-q] [<tree-ish>] [--] <pathspec>…gitreset[-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>]gitreset(--patch|-p) [<tree-ish>] [--] [<pathspec>…]gitreset[--soft|--mixed[-N] |--hard|--merge|--keep] [-q] [<commit>]
ОПИС
У перших трьох формах скопіюйте записи з <tree-ish> до індексу. В останній формі встановіть поточний заголовок гілки (HEAD) на <commit>, за бажанням змінюючи індекс та робоче дерево відповідно. <tree-ish>/<commit> за замовчуванням має значення HEAD у всіх формах.
-
gitreset[-q] [<tree-ish>] [--] <pathspec>... -
gitreset[-q] [--pathspec-from-file=<file> [--pathspec-file-nul]] [<tree-ish>] -
Ці форми скидають записи індексу для всіх шляхів, що відповідають <специфікації шляху>, до їхнього стану за станом <приблизно-дерево>. (Це не впливає на робоче дерево чи поточну гілку.)
Це означає, що
gitreset<шлях> є протилежністюgitadd<шлях>. Ця команда еквівалентнаgitrestore[--source=<деревоподібність>]--staged<шлях>....Після запуску
gitreset<pathspec> для оновлення запису індексу, ви можете скористатися git-restore[1] для перевірки вмісту індексу до робочого дерева. Або ж, використовуючи git-restore[1] та вказавши коміт з--source, ви можете скопіювати вміст шляху з коміту до індексу та до робочого дерева одночасно. -
gitreset(--patch|-p) [<tree-ish>] [--] [<pathspec>...] -
Інтерактивно вибирати фрагменти в різниці між індексом та <деревом-і-має> (за замовчуванням
HEAD). Вибрані фрагменти застосовуються до індексу у зворотному порядку.Це означає, що
gitreset-pє протилежністюgitadd-p, тобто ви можете використовувати його для вибіркового скидання ханків. Дивіться розділ "Інтерактивний режим" у git-add[1], щоб дізнатися, як працювати з режимом--patch. -
gitreset[<mode>] [<commit>] -
Ця форма скидає поточну головку гілки до <commit> та, можливо, оновлює індекс (скидаючи його до дерева <commit>) та робочого дерева залежно від <mode>. Перед операцією
ORIG_HEADвстановлюється на кінчик поточної гілки. Якщо <mode> пропущено, за замовчуванням використовується значення--mixed. <mode> має бути одним із наступних:-
--soft -
Зовсім не торкається індексного файлу чи робочого дерева (але скидає заголовок до <commit>, як це роблять усі режими). Це залишає всі ваші змінені файли "Зміни для коміту", як сказав би
gitstatus. -
--mixed -
Скидає індекс, але не робоче дерево (тобто змінені файли зберігаються, але не позначені для фіксації), та повідомляє про те, що не було оновлено. Це дія за замовчуванням.
Якщо вказано
-N, видалені шляхи позначаються як такі, що мають бути додані (див. git-add[1]). -
--hard -
Скидає індекс та робоче дерево. Будь-які зміни до відстежуваних файлів у робочому дереві з моменту <commit> відкидаються. Будь-які невідстежувані файли або каталоги, що заважають запису будь-яких відстежуваних файлів, просто видаляються.
-
--merge -
Скидає індекс та оновлює файли в робочому дереві, які відрізняються між <commit> та
HEAD, але зберігає ті, що відрізняються між індексом та робочим деревом (тобто ті, до яких внесено зміни, що не були додані). Якщо файл, який відрізняється між <commit> та індексом, містить неіндексовані зміни, скидання переривається.Іншими словами,
--mergeвиконує щось на кшталтgitread-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)
-
Ви із задоволенням працюєте над чимось і бачите, що зміни в цих файлах у порядку. Ви не хочете бачити їх, коли запускаєте
gitdiff, оскільки плануєте працювати над іншими файлами, а зміни в цих файлах відволікають. -
Хтось просить вас витягнути, і зміни звучать так, гідні об’єднання.
-
Однак, ви вже забруднили індекс (тобто ваш індекс не відповідає коміту
HEAD). Але ви знаєте, що вилучення, яке ви збираєтеся зробити, не впливає наfrotz.cабоfilfre.c, тому ви скасуєте зміни індексу для цих двох файлів. Ваші зміни в робочому дереві залишаються там. -
Потім ви можете витягнути та об’єднати, залишивши зміни
frotz.cтаfilfre.cу робочому дереві.
-
- Скасувати коміт та повторити
-
$ git commit ... $ git reset --soft HEAD^ (1) $ edit (2) $ git commit -a -c ORIG_HEAD (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)
-
Ви зробили кілька комітів, але зрозуміли, що їх передчасно помістити в гілку
master. Ви хочете продовжити їх полірування в тематичній гілці, тому створіть гілкуtopic/wipз поточної гілкиHEAD. -
Перемотайте master-гілку назад, щоб позбутися цих трьох комітів.
-
Перейдіть до гілки
topic/wipта продовжуйте роботу.
-
- Скасувати коміти назавжди
-
$ git commit ... $ git reset --hard HEAD~3 (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)
-
Спроба оновлення з основної платформи призвела до багатьох конфліктів; ви не були готові витрачати багато часу на злиття зараз, тому вирішили зробити це пізніше.
-
"pull" не створив коміт злиття, тому
gitreset--hard, що є синонімомgitreset--hardHEAD, очищає індексний файл та робоче дерево від безладу. -
Об’єднати тематичну гілку з поточною гілкою, що призвело до перемотування вперед.
-
Але ви вирішили, що тематична гілка ще не готова для публічного використання. "pull" або "merge" завжди залишає оригінальну кінчик поточної гілки в
ORIG_HEAD, тому скидання до нього повертає ваш індексний файл і робоче дерево до цього стану, а кінчик гілки скидається до цього коміту.
-
- Скасувати злиття або витягування всередині непрацюючого дерева
-
$ git pull (1) Автоматичне об'єднання nitfol Об'єднання, виконане рекурсивним способом. nitfol | 20 +++++---- ... $ git reset --merge ORIG_HEAD (2)
-
Навіть якщо у вашому робочому дереві є локальні зміни, ви можете сміливо сказати
gitpull, коли знаєте, що зміни в іншій гілці не перетинаються з ними. -
Після перевірки результату злиття ви можете виявити, що зміни в іншій гілці незадовільні. Виконання команди
gitreset--hardORIG_HEADдозволить вам повернутися до попереднього стану, але призведе до відкидання ваших локальних змін, чого ви не хочете. Командаgitreset--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)
-
Цей коміт буде видалено, тому повідомлення журналу про викидання буде прийнятним.
-
Це видаляє коміт «WIP» з історії комітів та встановлює ваше робоче дерево у стан безпосередньо перед створенням цього знімка.
-
На цьому етапі файл індексу все ще містить усі зміни незавершеного процесу, які ви зафіксували як «знімок незавершеного процесу». Це оновлює індекс, показуючи ваші незавершені файли як незакомічені.
Див. також git-stash[1].
-
- Скинути один файл в індексі
-
Припустимо, ви додали файл до свого індексу, але пізніше вирішили, що не хочете додавати його до свого коміту. Ви можете видалити файл з індексу, зберігаючи зміни, за допомогою команди git reset.
$ git reset -- frotz.c (1) $ git commit -m "Зафіксувати файли в індексі" (2) $ git add frotz.c (3)
-
Це видаляє файл з індексу, зберігаючи його в робочому каталозі.
-
Це закріплює всі інші зміни в індексі.
-
Знову додає файл до індексу.
-
- Зберегти зміни в робочому дереві, відкинувши деякі попередні коміти
-
Припустимо, ви працюєте над чимось і створюєте коміт, а потім продовжуєте працювати ще трохи, але тепер ви вважаєте, що те, що є у вашому робочому дереві, має бути в іншій гілці, яка не має нічого спільного з тим, що ви комітили раніше. Ви можете розпочати нову гілку та скинути її, зберігаючи зміни у вашому робочому дереві.
$ git tag start $ git switch -c branch1 $ edit $ git commit ... (1) $ edit $ git switch -c branch2 (2) $ git reset --keep start (3)
-
Це закріплює ваші перші редагування у
branch1. -
В ідеальному світі ви могли б усвідомити, що попередній коміт не належить до нової теми, коли створювали та перемикалися на
branch2(тобтоgitswitch-cbranch2start), але ніхто не ідеальний. -
Але ви можете скористатися
reset--keep, щоб видалити небажаний коміт після переходу наbranch2.
-
- Розділити коміт на послідовність комітів
-
Припустимо, що ви створили багато логічно окремих змін і закомітили їх разом. Потім, пізніше, ви вирішуєте, що, можливо, краще пов’язати кожен логічний фрагмент з власним комітом. Ви можете використовувати git reset для перемотування історії без зміни вмісту ваших локальних файлів, а потім послідовно використовувати
gitadd-pдля інтерактивного вибору фрагментів для включення до кожного коміту, використовуючиgitcommit-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)-
Спочатку скиньте історію на один коміт назад, щоб видалити оригінальний коміт, але залишити робоче дерево з усіма змінами. Параметр
-Nгарантує, що будь-які нові файли, додані за допомогоюHEAD, все ще будуть позначені, щобgitadd-pїх знайшов. -
Далі ми інтерактивно вибираємо ханки diff для додавання за допомогою функції
gitadd-p. Ця команда запитає вас про кожен ханк diff по черзі, і ви можете використовувати прості команди, такі як «так, включити це», «Ні, не включати це» або навіть дуже потужну функцію «редагувати». -
Щойно ви визначитеся з потрібними вам частинами змін, перевірте, що було підготовлено для першого коміту, використовуючи
gitdiff--cached. Це покаже всі зміни, які були переміщені до індексу та які ось-ось будуть закомічені. -
Далі закоміть зміни, що зберігаються в індексі. Опція
-cвказує на попереднє заповнення повідомлення коміту з оригінального повідомлення, з якого ви почали в першому коміті. Це корисно, щоб уникнути його повторного введення.HEAD@{1}— це спеціальна нотація для коміту, на якому знаходивсяHEADдо оригінального коміту reset (1 зміна тому). Дивіться git-reflog[1] для отримання додаткової інформації. Ви також можете використовувати будь-яке інше дійсне посилання на коміт. -
Ви можете повторити кроки 2-4 кілька разів, щоб розбити вихідний код на будь-яку кількість комітів.
-
Тепер ви розділили багато змін на окремі коміти та, можливо, більше не використовуєте режим патча команди
gitaddдля вибору всіх незбережених змін. -
Ще раз перевірте, чи ви включили те, що хотіли. Ви також можете переконатися, що git diff не показує жодних змін, які залишилися для подальшого коміту.
-
І нарешті створіть фінальний коміт.
-
ОБГОВОРЕННЯ
У таблицях нижче показано, що відбувається під час запуску:
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]