Інструменти професіонала й розв’язання проблем

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

1. Rollback — відкат локальних змін до останнього коміту

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

Використовуйте функцію Rollback:

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

IDE попередить вас, що незбережені зміни буде втрачено. Підтвердьте це — і файл миттєво повернеться до своєї останньої «чистої» версії в Git. Це найпростіший і найбезпечніший спосіб скасувати локальні експерименти.

2. Магія «Amend»: як доповнити останній коміт

Сценарій: ви щойно натиснули кнопку Commit і одразу зрозуміли, що забули додати один важливий файл (наприклад, оновлений тест) або припустилися безглуздої описки в повідомленні коміту. Створювати новий коміт із повідомленням «Додав забутий файл» — поганий тон.

Замість цього використовуйте функцію Amend (доповнити або виправити):

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

Замість створення нового «сміттєвого» коміту Git акуратно «розкриє» ваш попередній коміт, додасть туди нові файли, оновить повідомлення й запечатає все назад. Історія залишиться бездоганно чистою!

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

3. Undo Commit

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

Використовуйте функцію Undo Commit:

1. Відкрийте історію, вкладка Git -> Log внизу.
2. Клацніть правою кнопкою миші по самому верхньому, тобто вашому останньому, коміту.
3. Виберіть Undo Commit.

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

4. Reset — видалення локальної історії (Обережно!)

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

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

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

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

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

Ви експериментували локально, заплуталися в конфліктах, і проєкт перестав збиратися. Ви хочете сказати: «Git, видали все, що я тут накоїв, і зроби мою гілку такою ж чистою, як її версія на сервері GitHub».

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

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

В обох сценаріях IDE запропонує вам вибрати режим скидання. Для новачків важливо знати два з них:

• Mixed / Soft: Безпечний режим. Коміти зникнуть з історії, але всі зміни у файлах залишаться у вас у редакторі (як великий Undo). Ідеально підходить для Сценарію А, якщо ви хочете зібрати коміти заново.
• Hard: Радикальний режим. Безповоротно видаляє і коміти, і всі незакомічені зміни в коді. Ваш проєкт повністю повернеться до стану вибраного коміту. Саме цей режим потрібен для Сценарію Б, щоб ваша локальна гілка стала точною копією сервера. Використовуйте його лише тоді, коли на 100 % впевнені, що локально написаний код вам більше ніколи не знадобиться.

5. Що робити після Push?

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

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

Правильне та безпечне рішення:

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

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

Коли варто застосовувати Revert?

Хоча кнопка виглядає чарівною, до складного коду її потрібно застосовувати обережно. Коли історія комітів перетворюється на ланцюжок «Коміт → Коміт → Revert → Коміт», колегам під час code review буквально можна зламати голову, намагаючись зрозуміти, що зрештою працює, а що скасовано.

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

6. Stash / Shelve: як тимчасово сховати зміни

Сценарій: ви активно пишете код нової функції, і всі файли підсвічені червоним і синім. Раптом прибігає тімлід: «Кидай усе, терміново треба пофіксити баг у гілці main!». Ви не можете перемкнутися на main, тому що маєте незавершені конфліктні зміни. Робити коміт із напівготовим кодом теж не можна.

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

1. Відкрийте вікно Commit, виділіть змінені файли.
2. Клацніть правою кнопкою миші та виберіть Shelve Changes... (або Git -> Stash Changes).
3. Напишіть зрозумілу назву для цієї «закладки» і натисніть Shelve.

Ваші файли миттєво повернуться до початкового стану. Тепер ви можете безпечно перемкнутися на main, виправити баг, зробити коміт і відправити його. Коли термінове завдання буде виконано, поверніться у свою робочу гілку, відкрийте вкладку Shelf (Полиця), клацніть по своїх схованих змінах правою кнопкою і виберіть Unshelve. Ваш недописаний код повернеться на місце, і ви зможете продовжити роботу!

7. Зазирнути в минуле: просунута робота з логом

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

• Хеш коміту: ви, напевно, помітили в логу рядок із літерами та цифрами, наприклад a1b2c3d. Цей хеш — унікальний ідентифікатор кожного «знімка» вашого коду.
• Ви можете фільтрувати історію за гілкою, автором, датою або навіть за словом у повідомленні коміту. Це допомагає швидко знайти, хто і коли працював над певною частиною функціоналу.
• Хочете знайти коміт, у якому було додано або видалено конкретний рядок коду? У вікні Log є поле для пошуку, яке шукає не лише за повідомленнями, а й за вмістом самих змін.
• Клацніть правою кнопкою миші на полях редактора коду (там, де номери рядків) і виберіть Annotate with Git Blame. IDE покаже навпроти кожного рядка, хто і в якому коміті його востаннє змінював. Це неймовірно корисно для розуміння, чому код написано саме так.

8. Небезпечна зона: Force Push

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

Для таких випадків існує опція — force push (примусова відправка). Ця команда каже серверу: «Забудь усе, що в тебе було. Моя локальна версія історії — єдина правильна. Я заміню твою історію своєю».

УВАГА! У 99 % випадків використання force push у командних проєктах — це катастрофа. Це може безповоротно видалити коміти, які ваші колеги вже завантажили й на основі яких вони працюють.

Коли категорично НЕ МОЖНА використовувати force push:

• На будь-які спільні гілки: main, develop, master. Ніколи.
• На будь-яку гілку, з якою працює хтось іще, окрім вас.

Єдиний допустимий сценарій:

Ви працюєте у своїй особистій feature-гілці, яку ще ніхто не бачив і не завантажував. Ви зробили кілька «брудних» комітів, відправили їх на сервер, а потім вирішили об’єднати їх або виправити описку через Amend. У цьому випадку ви можете зробити force push, щоб оновити свою гілку на сервері перед створенням Pull Request.

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

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

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

Ми вже говорили про це в другій лекції, але ця тема настільки важлива для командної роботи, що ми виносимо її в окреме правило.

Завжди натискайте Update Project перед початком роботи над новим завданням і щоранку на початку робочого дня. Це вбереже вас від безлічі майбутніх конфліктів злиття і гарантує, що ви починаєте роботу з найактуальнішою версією коду, підтягнувши всі свіжі коміти ваших колег із сервера.

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

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

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

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

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

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

Група 3: Зміна і перенесення

• Cherry-Pick (Вишенька на торті) — неймовірно корисна команда! Дає змогу «витягнути» один конкретний коміт із чужої або іншої вашої гілки і скопіювати його у вашу поточну гілку. Наприклад, хтось в іншій гілці пофіксив баг, який блокує вашу роботу, — ви просто робите Cherry-Pick цього коміту до себе, не зливаючи (merge) всю чужу гілку цілком.
• 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).

11. Наостанок

Системи контролю версій можуть здаватися складними: гілки, злиття, конфлікти, лячні хеші комітів. Але пам’ятайте головне: Git — це ваша страхувальна сітка. Кожен Senior-розробник колись у паніці гуглив, як вийти зі стану detached HEAD або як скасувати випадковий push. Не бійтеся експериментувати. Помилятися локально — це абсолютно нормально, адже тепер у вас є повний арсенал інструментів IntelliJ IDEA, щоб скасувати, відкотити та виправити будь-яку помилку до того, як її побачить команда. Робіть коміти часто, пишіть зрозумілі повідомлення, завжди виконуйте Update Project вранці, і ви станете надійним і професійним учасником будь-якого проєкту.

12. Практичне завдання із зірочкою

Пропонуємо вам виконати невелике, але дуже хитре завдання. З цією проблемою стикаються 90 % розробників, коли починають працювати над кількома проєктами.

Ваше завдання:

1. Зареєструйте другий обліковий запис на GitHub з іншою адресою електронної пошти.
2. Додайте цей новий обліковий запис в IntelliJ IDEA.
3. Створіть новий репозиторій, склонуйте його, напишіть кілька рядків коду і зробіть Commit та Push, вибравши ваш новий обліковий запис.
4. А тепер зайдіть на сторінку git-log і уважно подивіться на історію комітів.

У чому підступ?

Найімовірніше, ви з подивом виявите, що автором коміту значиться ваш перший (основний) обліковий запис, хоча ви точно виконували push від імені нового профілю!

Дослідження:

Ваше завдання — розібратися, чому так сталося. Підказка: авторизація на сайті GitHub, щоб мати права на Push, і підпис автора всередині самого коміту — це не одне й те саме. Знайдіть спосіб через термінал перемкнути user.name і user.email так, щоб вони застосовувалися лише до цього конкретного проєкту, не ламаючи налаштувань вашого основного облікового запису. Зробіть новий коміт і добийтеся того, щоб в історії був коміт від облікового запису номер 2.