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

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

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

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

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

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

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

2. Reset — видалення локальних комітів

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

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

1. Відкрийте вкладку Git -> Log, щоб побачити історію комітів.
2. Знайдіть останній «хороший» коміт, до якого хочете повернутися (той, що був до помилкових).
3. Клацніть його правою кнопкою миші й виберіть 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 перед початком роботи над новим завданням. Це вбереже вас від багатьох майбутніх конфліктів злиття та гарантує, що ви починаєте роботу з найактуальнішою версією коду.

1

Опитування

Контроль версій, рівень 25, лекція 4

Недоступний

Контроль версій

Вступ до Git

Відкрити