Скидання гілок
Іноді хочеться скасувати цілу серію комітів і повернути гілку до попереднього стану.
Скажімо, я експериментував із новими можливостями в окремій гілці, але після кількох комітів зрозумів, що підхід не працює. Я хочу викинути всі ці експериментальні коміти й почати заново з місця, де гілка відгалузилася від main.
Саме тут стає в пригоді команда . Щоб змоделювати цей сценарій, спершу створімо нову гілку experiment.
git switch -c experimentСтвори нову гілку experiment і перемкнися на неї.
Чудово! Тепер створімо файл experiment.html. Додай усередину рядок This is an experiment., підготуй і закоміть зміни.
Виконай усі дії, описані вище.
Круто! Тепер видали рядок <!DOCTYPE html> з hello.html, підготуй і закоміть зміни.
Виконай усі дії, описані вище.
Гаразд, скажімо, у цей момент я протверезів зрозумів, що з експерименту нічого не виходить. Я хочу скинути гілку experiment до початкового стану й позбутися всіх експериментальних комітів.
Для цього використаємо команду git reset, вказавши посилання на коміт, до якого треба скинути гілку. У нашому випадку це коміт, від якого було створено гілку experiment, тобто останній коміт гілки main. Тож замість хеша коміту можна просто вказати назву цієї гілки: main.
git reset mainСкинь гілку experiment до останнього коміту з main.
Якщо зараз перевірити статус репозиторію, побачимо, що файл experiment.html нікуди не подівся, але Git вважає його невідстежуваним (untracked). Тобто файл не підготовлений і не закомічений.
А якщо заглянути в hello.html, там досі бракує <!DOCTYPE html>. Тобто робоче дерево насправді не змінилося — експериментальні зміни все ще в ньому.
Git пересунув вказівник гілки на той самий коміт, що й у гілці main. Коміти, зроблені в гілці experiment, більше не входять до її історії. Це називається mixed reset (змішане скидання): історія гілки відмотується назад, а зміни залишаються в робочому дереві, але зникають з області підготовки.
Якщо ці зміни потрібні, їх можна просто заново підготувати й закомітити, як зазвичай. Іноді саме це й треба. Наприклад, коли хочеться стиснути мільярд мікрокомітів в один осмислений коміт або, навпаки, розбити один величезний коміт на кілька менших.
Але в нашому випадку треба позбутися всіх експериментальних змін — тобто зробити hard reset (жорстке скидання).
До речі, чому б просто зараз не викинути всі зміни з робочого дерева? Використай команду, яку ми вивчили раніше (підказка: вона починається на букву r і римується з chore). Якщо команда вилетіла з голови, зазирни в .
Скасуй зміни в робочому дереві.
Чудова робота! Насправді жорстке скидання можна було зробити однією командою, додавши до git reset опцію --hard. Команда git reset --hard не раз рятувала мене від зайвого клопоту.
Перевірмо статус репозиторію.
git statusПеревір статус репозиторію.
Зміни в hello.html зникли. Але файл experiment.html досі на місці! Чому так?
Цей файл невідстежуваний, тож Git про нього нічого не знає. Він не входить до репозиторію, тому команда скидання його не зачіпає. Щоб повністю позбутися файла, його можна просто видалити командою .
rm experiment.htmlВидали файл experiment.html.
Тепер перевірмо статус репозиторію.
git statusПеревір статус репозиторію.
Чудово! Гілка повернулася до стану, у якому була на момент створення.
Перш ніж рухатися далі, перемкнімося на гілку main.
Якщо зміни зі скасованих комітів треба зберегти, використовуй git reset --soft замість git reset. Вказівник гілки скинеться, але всі зміни зі скасованих комітів залишаться в області підготовки.
А якщо треба стерти всі сліди скасованих комітів, використовуй git reset --hard. Це скине вказівник гілки й видалить усі зміни в робочій директорії та області підготовки. Тут потрібна максимальна обережність!
Будь обережніше з git reset, особливо з опцією --hard: вона може безповоротно знищити зміни. Завжди перевіряй, що скидання йде до правильного коміту. Якщо незакомічені зміни ще можуть знадобитися, збережи їх через git stash перед скиданням.
Команда git reset трохи схожа на git restore, принаймні назвами. Обидві можуть скасовувати зміни в робочому дереві. Але git restore новіша й уміє менше: вона відновлює файли в робочому дереві, але не рухає вказівник гілки. Власне, саме для цього її й додали: щоб відокремити переміщення вказівника гілки від відновлення файлів. З git restore менше шансів випадково щось зламати — вона точковіша й менш руйнівна, ніж git reset.
Щоправда, тим, хто звик до старої git reset, доведеться якийсь час перевчатися на нову команду. Але якщо знайомство з Git тільки починається, варто розібратися в різниці й там, де це доречно, використовувати git restore замість git reset.
Проходь курс так, як він і задуманий: маленькими порціями, у сфокусованому лінійному порядку, поступово відкриваючи статті Gitopedia. Будь-коли можна продовжити зі справжнім Git у VS Code/Cursor/Antigravity/Windsurf.
але потрібен вхід