Скасування і відновлення змін у Git

Досі ми розглядали ідеальний сценарій: ви пишете код, робите коміти, створюєте Pull Request. Але в реальному житті часто щось не виходить: ви забули додати файл, зробили одрук у повідомленні коміту або зрозуміли, що звернули не туди. У цій статті розберемо, як розв'язувати найчастіші проблеми інструментами IDE.

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

Коли в проєкті працює Claude Code, збережена історія допомагає відновити попередній результат. Але Git не зберігає кожне натискання клавіші, тож незакомічені правки цілком можна втратити. Перед скасуванням перевірте гілку, вибрані файли і те, чи є потрібна копія.

Rollback - відкат локальних змін

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

Скористайтеся функцією Rollback:

1. відкрийте вкладку Commit на лівій панелі;
2. знайдіть у списку змінений файл (або виділіть кілька), який хочете відкотити;
3. клацніть правою кнопкою і виберіть Rollback (або натисніть іконку із закругленою стрілкою).

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

Amend - доповнити останній коміт

Сценарій: ви щойно натиснули Commit і тут же збагнули, що забули додати важливий файл (наприклад, оновлений тест) або зробили одрук у повідомленні. Якщо коміт ще не опубліковано, можна скористатися Amend. Окремий виправний коміт теж годиться, особливо для вже спільної історії.

Щоб доповнити неопублікований коміт, скористайтеся функцією Amend (доповнити/виправити):

1. у вікні Commit внесіть виправлення в забутий файл і поставте біля нього позначку;
2. на панелі Commit Message знайдіть чекбокс Amend (або іконку шестірні -> Amend Commit) і позначте його;
3. IDE підтягне повідомлення попереднього коміту - його можна відредагувати;
4. натисніть Commit.

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

Докладніше про цю функцію - в офіційному туторіалі JetBrains.

Undo Commit

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

Скористайтеся функцією Undo Commit:

1. відкрийте історію - вкладка Git -> Log унизу;
2. знайдіть останній коміт саме поточної гілки (HEAD), а не просто верхній рядок загального графа, і відкрийте його контекстне меню;
3. виберіть Undo Commit.

Виберіть список змін (зазвичай Default Changelist) і натисніть OK. Коміт зникне з історії, а файли повернуться у вікно Commit зі статусом змінених. Ви нічого не втратили, можна спокійно писати код далі. От і все.

Reset - переміщення гілки і стан файлів

Функція Reset Current Branch to Here... - потужний інструмент, який переміщує вказівник вашої гілки на будь-який вибраний коміт. Залежно від ситуації вона може як делікатно скасувати останні дії, так і радикально стерти зламаний код.

Сценарій А - скасування останніх локальних комітів

Ви зробили кілька комітів локально (до Push) і зрозуміли, що весь цей напрям розробки, м'яко кажучи, був помилковим.

1. відкрийте вкладку Git -> Log;
2. знайдіть останній хороший коміт, на якому хочете опинитися (той, що був до серії помилкових);
3. клацніть на ньому правою кнопкою і виберіть Reset Current Branch to Here....

Сценарій Б - скидання до стану сервера

Ви хочете відновити відстежувані файли за віддаленою гілкою. Спершу збережіть потрібну локальну роботу і виконайте Fetch: мітка origin/main показує останній отриманий стан сервера, а не той, що постійно оновлюється. Якщо зараз триває конфліктна операція, спочатку розберіть і завершіть або скасуйте її; не використовуйте Hard як універсальні ліки.

1. відкрийте Git -> Log;
2. знайдіть маркер віддаленої гілки - зазвичай це коміт із фіолетовою міткою origin/main (або origin/назва_вашої_гілки). Це останній відомий стан коду на сервері;
3. клацніть на цьому коміті правою кнопкою і виберіть Reset Current Branch to Here....

Режими скидання

У вікні скидання вибирайте режим свідомо. У всіх трьох варіантах поточна гілка переміщується до вибраного коміту, а от доля індексу й робочих файлів різна:

• Soft зберігає робочі файли й індекс. Mixed зберігає робочі файли, але приводить індекс до вибраного коміту: різниця лишається непідготовленою. Це різні режими, хоча обидва дають змогу працювати далі із вмістом файлів;
• Hard приводить індекс і відстежувані файли до вибраного коміту та знищує їхні незакомічені правки. Звичайні сторонні untracked-файли можуть залишитися, а шляхи, що заважають відновленню, може бути видалено. Коміти не стираються негайно з усіх сховищ, але розраховувати, що роботу потім вдасться врятувати, не можна.

Що робити після push

Сценарій: ви зробили push і лише потім помітили помилку.

Щойно коміт потрапив на сервер, він стає частиною спільної історії проєкту. Спроба переписати цю історію (через Reset або Amend) може створити величезні проблеми для колег - уявіть, що вони вже завантажили ваші зміни й почали на їхній основі свою роботу.

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

В IDE також є спеціальна функція Revert Commit. Якщо клацнути правою кнопкою на помилковому коміті у вікні Git -> Log і вибрати Revert Commit, IDE створить новий "антикоміт", який робить прямо протилежне помилковому (наприклад, видалить додані рядки).

Revert корисний, коли опубліковану зміну треба скасувати новим комітом. Він підходить і для коду, і для тексту, але може конфліктувати з пізнішими правками. Після розв'язання конфлікту перевірте, що вийшло; для складної залежності іноді зрозуміліше окреме виправлення.

Stash / Shelve - тимчасово сховати зміни

Сценарій: ви активно пишете код нової фічі, усі файли червоні й сині. Раптом прибігає тимлід: "кидай усе, терміново треба пофіксити баг у гілці main". Перемкнутися на main ви не можете - є незавершені конфліктні зміни. Проміжний локальний коміт можливий за правилами проєкту, але якщо фіксувати роботу зараз незручно, її можна відкласти.

Рішення - тимчасово сховати роботу у віртуальну коробку. У Git це називається Stash, а в IDE є окремий механізм - Shelve (відкласти на полицю).

1. відкрийте вікно Commit, виділіть змінені файли;
2. виберіть Shelve Changes...; ці кроки стосуються Shelve, а Git Stash викликається окремо;
3. напишіть зрозумілу назву для цієї закладки й натисніть Shelve.

Після Shelve перевірте файли, що лишилися. Чи справді відкладено всі потрібні правки? Тепер можна перемкнутися на main, виправити помилку і зберегти результат за правилами проєкту. Потім поверніться в робочу гілку, відкрийте Shelf і виберіть Unshelve.

Для Git Stash використовуйте окремий список stash і відновіть потрібний запис. Це інше сховище. Звичайний stash не бере нові untracked-файли без додаткової опції; до перемикання перевірте, що вся потрібна робота збережена. Відновлення може конфліктувати, тож після нього знову перевірте файли.

Просунута робота з логом

Вікно Git -> Log - це не просто список комітів, а справжній інструмент для розслідувань.

• Хеш коміту - рядок із літер і цифр, наприклад a1b2c3d. Це унікальний ідентифікатор кожного знімка вашого коду.
• історію можна фільтрувати за гілкою, автором, датою або словом у повідомленні коміту - так швидко знаходиш, хто і коли працював над певною частиною;
• щоб знайти коміт, де було додано або видалено конкретний рядок коду, у вікні Log є пошук не лише за повідомленнями, а й за вмістом змін;
• клацніть правою кнопкою на полях редактора (де номери рядків) і виберіть Annotate with Git Blame - IDE покаже біля кожного рядка, хто і в якому коміті змінював його останнім. Потім відкрийте коміт і пов'язане обговорення: сам Blame показує останню правку рядка, але не пояснює її причину.

Небезпечна зона - Force Push

Ми з'ясували, що змінювати надіслані коміти - погана ідея. Але що, як ви все-таки змінили свою локальну історію (наприклад, через Undo Commit або Amend), а на сервері вже лежить стара версія? Під час звичайного push Git видасть помилку, захищаючи спільну історію від перезапису.

Force push дозволяє замінити вибране віддалене посилання навіть тоді, коли нова історія не продовжує попередню. Це не очищення всього сервера: наслідки залежать від посилань, які ви надсилаєте. Захист гілки може заборонити таке надсилання.

Force push може прибрати з віддаленої гілки коміти, яких немає у вашій локальній історії. Тому на спільній гілці переписування потребує окремого погодженого рішення команди. Для звичайного виправлення використовуйте новий коміт або Revert.

Типовий випадок, коли force push варто обговорювати, - власна гілка після погодженого переписування її історії. Навіть тут перевірте, чи немає чужих нових комітів. Варіант --force-with-lease додає перевірку очікуваного стану віддаленої гілки, але не скасовує потреби розуміти, які коміти буде замінено.

На знімку Force Push сховано у спадному меню кнопки Push. Перед використанням перевірте, який режим примусового надсилання застосовує ваша версія IDE.

Якщо не впевнені на 100%, що робите, - не використовуйте force push. Безпечніше створити новий коміт із виправленнями (або скористатися Revert).

Оновлення проєкту

Перед новим завданням перевірте вихідну гілку й незавершені зміни. Отримуйте оновлення, коли це потрібно, і читайте результат об'єднання. Update Project не гарантує, що конфліктів не буде, і може використовувати merge або rebase залежно від налаштувань.

Після оновлення перевірте поточну гілку, список комітів і стан файлів. З'явилися конфлікти? Спершу розберіть їх, а вже потім продовжуйте завдання.

Контекстне меню Git Log

Коли ви відкриваєте вкладку Git -> Log і клацаєте правою кнопкою на будь-якому коміті, з'являється велике контекстне меню. Розберемо найкорисніші команди, згруповані за завданнями.

Група 1 - перегляд і аналіз (безпечні дії)

• Copy Revision Number - копіює унікальний хеш коміту в буфер обміну. Корисно, щоб скинути посилання на коміт колезі або вказати його в тікеті (Jira, YouTrack);
• Compare with Local - порівнює стан файлу зі старого коміту з тим, що у вас зараз у редакторі. чудовий спосіб зрозуміти, який вигляд цей код мав місяць тому;
• Show Repository at Revision - відкриває структуру всіх файлів проєкту в тому стані, у якому вони були на момент цього коміту (поточна гілка при цьому не змінюється).

Група 2 - робота з гілками

• New Branch... - створює нову гілку безпосередньо від вибраного коміту в минулому. Незамінна річ, якщо ви пішли далеко вперед, зрозуміли, що все зламали, і хочете почати нову гілку від останнього робочого місця;
• Checkout Revision - перемикає локальний проєкт на цей коміт. Ви опинитеся в стані від'єднаної голови (detached HEAD): можна запустити старий код, але нові коміти не прив'яжуться до жодної гілки. Якщо створили потрібні коміти в detached HEAD, спершу збережіть їх новою гілкою. Щоб повернутися, зробіть Checkout звичайної гілки (наприклад, main).

Група 3 - зміна і перенесення

• Cherry-Pick - дає змогу висмикнути один конкретний коміт з іншої гілки й скопіювати його в поточну. Наприклад, хтось в іншій гілці пофіксив баг, який блокує вашу роботу - ви робите Cherry-Pick цього коміту до себе, не зливаючи всю чужу гілку цілком;
• Edit Commit Message... - якщо коміт ще не надіслано (не було Push), можна швидко змінити його повідомлення. Зручніше, ніж Amend, коли треба змінити тільки текст.

Група 4 - скасування змін

Ці команди ми докладно розібрали вище:

• Reset Current Branch to Here... - зсуває поточну гілку на цей коміт (змінюючи історію, доступну з цієї гілки);
• Revert Commit - створює "антикоміт", щоб скасувати змінений вміст новим локальним комітом, який потім надсилають на сервер;
• Undo Commit... - розбирає локальний коміт назад у вікно змін.

Група 5 - переписування історії

У меню є й такі команди, як Squash Commits... (об'єднати кілька комітів в один), Drop Commits (видалити коміт із середини історії) або Interactively Rebase from Here.... Це інструменти тонкої хірургічної роботи над локальною історією (Interactive Rebase).

Git - ваша страхувальна сітка

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

Як це працює у зв'язці з Claude Code

Коли в проєкті працює Claude Code, ці інструменти - ваш головний захист. На практиці все зводиться до кількох простих правил:

• робіть коміти часто: кожен коміт - точка повернення. Якщо агент піде не туди, ви відкотитеся до останнього робочого стану;
• щоб скасувати незакомічені правки, спершу відокремте потрібні зміни, потім перевірте область і джерело відновлення в Rollback або git restore;
• якщо коміт уже зроблено, але не надіслано - Undo Commit поверне зміни в редактор;
• якщо помилка вже на сервері - безпечніше новий коміт із фіксом або Revert, а не переписування історії.

Попередня стаття: Pull request від створення до злиття · Наступна стаття: Створення репозиторію, rebase і секрети