Досі ми розглядали ідеальний сценарій: ви пишете код, робите коміти, відкриваєте Pull Request. Та в реальному житті не все йде гладко: можна помилитися в коді, зробити коміт із невдалим повідомленням або зрозуміти, що рухаєтеся не туди. У цій лекції ми розглянемо, як розвʼязувати найпоширеніші проблеми.
1. Rollback — скасування змін до коміту
Сценарій: ви змінили файл, але зрозуміли, що всі ваші правки хибні, і хочете швидко повернути файл до стану, у якому він був після останнього коміту.
Скористайтеся функцією Rollback:
- Відкрийте вкладку
Commit. - Знайдіть у списку змінений файл, який ви хочете «відкотити».
- Клацніть його правою кнопкою миші й виберіть
Rollback.
IDE попередить вас, що зміни буде втрачено. Погодьтеся — і файл миттєво повернеться до своєї останньої збереженої в Git версії. Це найпростіший і найбезпечніший спосіб скасувати локальні зміни.
2. Reset — видалення локальних комітів
Сценарій: ви зробили один або кілька комітів, але ще не робили push. Ви зрозуміли, що ці коміти хибні, і хочете їх повністю видалити, наче їх і не було.
Скористайтеся функцією Reset:
- Відкрийте вкладку
Git → Log, щоб побачити історію комітів. - Знайдіть останній «хороший» коміт, на якому ви хочете опинитися (той, що був до помилкових).
- Клацніть його правою кнопкою миші й виберіть
Reset Current Branch to Here....
У вікні, яке відкрилося, вам запропонують вибрати режим скидання. Найрадикальніший — Hard.
Увага! Режим Hard безповоротно видаляє всі коміти після обраного, а також усі зміни в коді, які були в цих комітах. Використовуйте його з великою обережністю й тільки для тих комітів, які ще ніхто не бачив (ті, що не були надіслані на GitHub).
3. Що робити після Push?
Сценарій: ви зробили push, і лише потім помітили в ньому помилку.
Щойно коміт потрапляє на віддалений сервер, він стає частиною спільної історії проєкту. Спроба переписати цю історію може створити великі проблеми для ваших колег. Уявіть, що вони вже завантажили ваші зміни й почали на їхній основі свою роботу.
Правильне й безпечне рішення:
Просто зробіть новий коміт, який виправляє помилку, і надішліть його. Це абсолютно нормальна практика. Так історія лишається чесною й зрозумілою для всіх.
4. Зазирнути в минуле: просунута робота з журналом
Ми вже знайомі з вкладкою Git → Log, але це не просто список комітів, а потужний інструмент для аналізу й розслідувань.
- Хеш коміту (Commit Hash): ви, напевно, помічали в журналі рядок із літер та цифр, наприклад
a1b2c3d. Цей хеш унікальний: він дає змогу точно посилатися на будь-яку точку в історії проєкту. Вам рідко знадобиться використовувати його вручну, але важливо знати, що це й є унікальний ідентифікатор кожного «знімка» вашого коду.![]()
- Ви можете фільтрувати історію за гілкою, автором, датою або навіть за словом у повідомленні коміту. Це допомагає швидко знайти, хто й коли працював над певною частиною функціональності.
- Хочете знайти коміт, у якому було додано або видалено конкретний рядок коду? У вікні
Logє поле пошуку, яке шукає не лише в повідомленнях, а й у вмісті самих змін. - Клацніть правою кнопкою миші на полях редактора коду й виберіть
Annotate with Git Blame. IDE покаже навпроти кожного рядка, хто й у якому коміті його востаннє змінював. Це надзвичайно корисно, щоб зрозуміти, чому код написано саме так.
5. Небезпечна зона: Force Push
Отже, ми зʼясували, що змінювати надіслані коміти — погана ідея. Але що, як ви таки змінили свою локальну історію (наприклад, за допомогою Reset) і тепер вона розходиться з історією на сервері? Під час спроби зробити звичайний push Git видасть помилку, захищаючи спільну історію від перезапису.
Для таких випадків існує опція — force push (примусове надсилання). Ця команда каже серверу: «Забудь усе, що в тебе було. Моя локальна версія історії — єдина вірна. Заміні свою історію моєю».
УВАГА! У 99 % випадків використання force push у командних проєктах — це катастрофа. Це може безповоротно видалити коміти, які ваші колеги вже завантажили й на основі яких вони працюють. Це все одно що вирвати сторінки зі спільної бібліотечної книги й вклеїти свої.
Коли категорично НЕ МОЖНА використовувати force push:
- На будь-які спільні гілки:
main,develop,master. Ніколи. - На будь-яку гілку, з якою працює хтось інший, окрім вас.
Єдиний допустимий сценарій:
Ви працюєте у своїй особистій feature‑гілці, яку ще ніхто не бачив і не використовував. Ви зробили кілька «брудних» комітів, надіслали їх на сервер, а потім вирішили їх «упорядкувати» за допомогою Reset. У такому разі ви можете виконати force push, щоб оновити свою гілку на сервері перед створенням Pull Request.
В IDE ця опція зазвичай схована за кнопкою Push. Розробники IDE зробили це навмисно, щоб ви її випадково не натисли.
Якщо ви не впевнені на 100 %, що робите, — ніколи не використовуйте force push. Безпечніше створити новий коміт із виправленнями.
6. Оновлення проєкту
Завжди натискайте Update Project на гілці main перед початком роботи над новим завданням. Це вбереже вас від численних майбутніх конфліктів злиття й гарантує, що ви починаєте роботу з найактуальнішою версією коду.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ