Як ти вирішуєш конфлікти при злитті гілок перед релізом?

Конфлікти при злитті - звичайна частина командної розробки, особливо перед релізом, коли в коді сходяться десятки змін. Головне - не панікувати і діяти системно, з пріоритетом на прозорість і стабільність.

---

#1. Мінімізую ймовірність конфліктів заздалегідь

• Часто синхронізуюся з develop - не чекаю тижнів, щоб "влити все одразу".
• Дрібні, короткі гілки: чим менше змін, тим простіше їх інтегрувати.
• Спільні стандарти форматування (Prettier, ESLint, Black) - щоб уникнути конфліктів через пробіли і стиль.

---

#2. При виявленні конфлікту - аналіз контексту

• Запускаю git merge або git rebase, дивлюся, в яких файлах і чому конфлікт.
• Визначаю: це та сама логіка, видалений код, чи різні частини функції.
• Порівнюю з історією комітів (git log -p, git blame), щоб зрозуміти, хто і навіщо вніс зміни.

---

#3. Розрулюю вручну за допомогою IDE або командного рядка

• Використовую візуальні інструменти (VS Code, IntelliJ, Meld) - вони показують відмінності порядково.
• Зберігаю обидва варіанти, якщо є сумнів, і обговорюю з автором.
• Після вирішення - обов'язково запускаю збірку і тести, щоб переконатися, що нічого не зламано.

---

#4. Перевіряю наслідки

• Локально прогоняю юніт- і інтеграційні тести.
• Якщо зміни зачіпають спільні модулі - створюю тимчасовий білд на CI для перевірки всієї системи.

---

#5. Комунікую з командою

• Повідомляю в чат або PR: "Були конфлікти в auth-service.js, перевірив ще раз, тести зелені".
• Якщо логіка спірна - обговорюємо з автором до мержу.
• При масових конфліктах влаштовуємо коротку "merge session" усією командою.

---

#Висновок

Вирішення конфліктів - це не просто технічна операція, а управління ризиками перед релізом. Головне - часті синхронізації, прозоре спілкування і обов'язкова перевірка після мержу. Так навіть складні конфлікти вирішуються спокійно і без втрат для продукту.