7.7 Інструменти Git - Усвідомлення скидання (reset)

Набагато легше зрозуміти reset та checkout, якщо уявити, що Git керує вмістом трьох різних дерев. Деревом'' ми тут називатимемо колекцію файлів'', а не саме структуру даних. (Є декілька випадків, в яких індекс насправді не поводиться як дерево, проте легше поки що уявляти його так.)

Git як система керує та маніпулює трьома деревами під час нормальної роботи:

Головне призначення Git - записувати знімки вашого проекту в послідовно кращих станах за допомогою маніпулювання цими трьома деревами.

Уявімо собі цей процес: припустімо, ви переходите до нової директорії з єдиним файлом у ній. Ми назвемо цю версію файла v1, та будемо позначати її синім. Тепер виконаємо git init, що створить сховище Git з посиланням HEAD, що вказує на ненароджену гілку (master ще не існує).

Наразі тільки в дереві Робочої Директорії є якийсь вміст.

Тепер ми бажаємо зробити коміт з цим файлом, отже ми використовуємо git add щоб взяти вміст з Робочої Директорії та скопіювати його до Індексу.

Потім виконуємо git commit, що бере вміст Індексу та зберігає його в незмінному знімку, створює обʼєкт коміту, що вказує на цей знімок, та оновлює master, щоб той вказував на цей коміт.

Якщо ми виконаємо git status, то не побачимо ніяких змін, адже всі три дерева однакові.

Тепер ми хочемо зробити зміну в цьому файлі та зберегти їх у коміті. Ми пройдемо той самий процес. Спочатку змінимо файл у робочій директорії. Назвемо цю версію файла v2, та позначимо її червоним.

Якщо ми зараз виконаємо git status, то побачимо файл червоним у `Changes not staged for commit'', адже в цього елемента є різниця між Індексом та Робочою Директорією. Далі виконуємо `git add на ньому, щоб додати його до Індекса.

Тепер, якщо ми виконаємо git status, то побачимо файл зеленим під `Changes to be commited'', адже Індекс та HEAD різняться — тобто, наш пропонований наступний коміт зараз відрізняється від останнього коміту. Нарешті, виконуємо `git commit щоб завершити коміт.

Тепер git status нічого не виведе, адже всі три дерева знову однакові.

Переключення гілок та клонування проходить за схожим процесом. Коли ви отримуєте (checkout) гілку, Git перенаправляє HEAD до нового посилання гілки, заповнює Індекс знімком того коміту, далі копіює вміст Індексу до Робочої Директорії.

Команду reset легше зрозуміти в цьому контексті.

Задля наступних прикладів, скажімо ми змінили файл file.txt знову та зробили третій коміт. Отже тепер наша історія виглядає так:

Розгляньмо ґрунтовно що саме робить команда reset при виклику. Вона безпосередньо змінює ці три дерева в простий та передбачуваний спосіб. Вона здійснює три базові операції.

Ми розглянули поведінку reset у базовому випадку, проте їй також можна передати шлях, що його треба обробити. Якщо задати шлях, reset пропустить крок 1, та обмежить решту своїх дій файлом або декількома файлами. Це доволі розумно — HEAD є просто вказівником та не може вказувати на частину одного коміту та частину іншого. Проте Індекс та Робоча директорія можуть бути частково оновленими, отже скидання йде далі до кроків 2 та 3.

Отже, припустіть, що ми виконали git reset file.txt. Цей формат (адже ви не вказали SHA-1 коміту або гілку, та не задали --soft або --hard) є скороченням git reset --mixed HEAD file.txt, що:

Отже суттєво просто копіює file.txt з HEAD до Індексу.

Це має ефект деіндексації файла. Якщо подивитися на зображення, та згадати, що робить git add, то зрозуміло що вони роблять цілковито протилежні речі.

Ось чому вивід команди git status пропонує виконувати цю команду для деіндексації файла. (Докладніше в Вилучання файла з індексу.)

Ми могли б так же легко не давати Git припускати, що ми маємо на увазі `візьми дані з HEAD'', якби б задали окремий коміт, з якого треба брати версію. Ми могли просто виконати щось на кшталт `git reset eb43bf file.txt.

Ця досягає такого ж ефекту, ніби ми повернули вміст файлу до v1 у Робочій Директорії, виконали на ньому git add, а потім повернули його вміст до v3 знов (тільки без проходження всіх цих кроків). Якщо тепер виконати git commit, буде записано зміну, що повертає файл до стану v1, хоча ми ніколи не мали його в такому стані в Робочій Дирикторії.

Також цікаво знати, що як і команда git add, reset приймає опцію --patch щоб деіндексувати вміст файлу по шматкам. Отже ви можете вибірково деіндексувати або скасовувати вміст.

Подивімося на те, як можна зробити щось цікаве цією винайденою можливістю — зварювання комітів.

Припустімо у вас є послідовність комітів з повідомленнями oops.'', WIP'' та `forgot this file'' (забув цей файл). Ви можете використати `reset щоб швидко та легко зварити їх в один коміт, що дозволяє вам виглядати дійсно витонченим. (У Зварювання комітів йдеться про інший спосіб це зробити, проте в даному випадку легше скористатися reset.)

Скажімо у вас є проект, в якому перший коміт містить один файл, другий додав новий файл та змінив перший, а третій знову змінив перший файл. Другий коміт був незавершеною працею та ви бажаєте його зварити з останнім.

Ви можете виконати git reset --soft HEAD~2 щоб перемістити гілку HEAD назад до старшого коміту (найновішого коміту, який ви бажаєте залишити):

Та просто знову виконати git commit:

Тепер, як бачите, ваша досяжна історія, історія яку ви будете викладати, тепер виглядає ніби ви зробили були лише коміт з file-a.txt першої версії, потім другий коміт та коміт, що змінив file-a.txt до третьої версії та додав file-b.txt. Коміт з другою версією файла більше не існує в історії.

Нарешті, вам може бути цікаво в чому різниця між checkout та reset. Як і reset, checkout маніпулює трьома деревами, проте трохи по-іншому в залежності від того, даєте ви їй окремі файли чи ні.

Сподіваємось, що тепер ви розумієте і почуваєтесь комфортніше з командою reset, проте ймовірно досі трохи спантеличені, чим саме вона відрізняється від checkout та навряд чи запам’ятали всі правила різноманітних форм викликів.

Ось шпаргалка щодо того, як команди впливають на які дерева. Колонка HEAD'' має значення ПОС'' (посилання), якщо переміщує посилання (гілку), на яке вказує HEAD, або ``HEAD'', якщо переміщує сам HEAD. Приділить особливу увагу колонці 'РД у Безпеці?' (РД - робоча директорія) — якщо в ній НІ, двічі поміркуйте перш ніж виконати команду.