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

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

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

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

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

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

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

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

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

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

1. У вікні Commit внесіть потрібні правки в забутий файл і поставте навпроти нього позначку.
2. У панелі повідомлення коміта знайдіть прапорець 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 -> Коміт», вашим колегам під час код-ревʼю можна буквально «зламати голову», намагаючись зрозуміти, що в підсумку працює, а що скасовано.

Зате 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.