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

Досі ми розглядали ідеальний сценарій: ви пишете код, робите коміти, створюєте 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 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 — це ваша страхувальна сітка. Кожен досвідчений розробник колись у паніці шукав у Google, як вийти зі стану «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.