Модуль 9 · урок 7 з 9

Конфлікти й історія

Конфлікт — це не поломка, а питання: двоє змінили той самий рядок, і Git не знає, чия версія правильна. Він чесно каже про це й чекає рішення. Страшно виглядає лише перший раз.

Як він виглядає

<<<<<<< HEAD
  readonly pageSize = 25;
=======
  readonly pageSize = 50;
>>>>>>> feature/12-status-filter

Угорі — версія з гілки, на яку ти вливаєш (зазвичай main). Унизу — твоя. Треба лишити правильний варіант і прибрати всі три маркери. Забутий >>>>>>> у коді — класика, яка потім падає з незрозумілою синтаксичною помилкою.

git status                 # покаже, які файли в конфлікті
# … правиш файли руками …
git add src/app/config.ts  # позначаєш вирішеним
git rebase --continue      # або git merge --continue

Merge чи rebase

# підтягнути свіжий main у свою гілку
git fetch origin
git rebase origin/main         # історія лишиться прямою

# якщо щось пішло не так — завжди можна скасувати
git rebase --abort

Як не створювати конфліктів

• Маленькі гілки. День-два життя — і перетинів майже не буває.
• Регулярний rebase origin/main. Раз на день, а не раз на тиждень: один конфлікт із двох рядків замість двадцяти з двохсот.
• Домовленість про зони. Якщо двоє переробляють один файл — краще домовитись голосом, а не в Git.
• Форматування окремо. Автоформатування всього проєкту гарантує конфлікт у кожній відкритій гілці.

Коли зламав щось у себе

git reflog                          # історія ВСІХ переміщень HEAD, навіть «втрачених»
git reset --hard HEAD@{3}           # повернутись до стану три кроки тому

git restore src/file.ts             # скасувати зміни у файлі
git reset --soft HEAD~1             # скасувати останній коміт, лишивши зміни
git revert <hash>                   # окремий коміт, який скасовує інший — безпечно для спільних гілок

git reflog — це страховка від майже будь-якої помилки. Git не видаляє коміти одразу, тож «утрачена» робота зазвичай знаходиться. Якщо здається, що все пропало — спершу reflog, і лише потім паніка.