Конфлікти та стратегія злиття треків

Git-конфлікт може бути семантичним

Конфлікт — це не лише одночасна зміна одного рядка. Небезпечні проблеми виникають у бізнес-логіці, API-контрактах, припущеннях команд, ownership і змінах поза scope. Git може обʼєднати текст, але не виявити подвійне застосування знижки або зміну порядку обчислень.

Результат потрібно оцінювати не за тим, чий варіант виглядає переконливіше, а за ownership, scope discipline, evidence і ціною помилки.

Алгоритм розбору двох треків

1. Порівняйте diff кожної гілки з main.
2. Окремо зіставте зміни треків між собою.
3. Перевірте ownership і scope.
4. Перегляньте тести, логи та інші артефакти.
5. Перевірте спільний контракт: сигнатури, порядок обчислень і helper-и.
6. Оберіть спосіб інтеграції.
7. Зафіксуйте рішення в журналі сесії.

Варіанти інтеграції

Наприклад, із promo-треку можна перенести лише тести округлення, а сумнівний рефакторинг залишити для окремої задачі.

Як запобігати конфліктам

• описувати scope та ownership у brief кожного треку;
• забороняти непогоджені зміни в сусідніх модулях;
• зберігати правила роботи в CLAUDE.md;
• вести parallel-session-log.md;
• додавати контрактні та інтеграційні тести на межах;
• розділяти змішані або надто широкі diff до merge.

Журнал рішення про конфлікт

Conflict: track-a vs track-b
Type: shared API contract
Trusted track: backend owner
Decision: cherry-pick tests only
Reason: refactor exceeded scope
Follow-up: separate architecture task