конфлікт (merge conflict)
Також називають: конфлікт мерджу
Ситуація, коли дві гілки по-різному змінили ті самі рядки, тож Git не може об'єднати їх автоматично і людина має вирішити, який буде результат.
Коли Git мерджить дві гілки, він порівнює кожну сторону з комітом, де вони розійшлися. Зміни в різних місцях об'єднуються автоматично. Коли обидві сторони по-різному змінили ті самі рядки, Git не може знати, яка версія правильна, зупиняється й позначає це місце у файлі: <<<<<<< ваша сторона, =======, інша сторона, >>>>>>>. Людина вирішує, яким буде результат, прибирає маркери й завершує мердж. На GitHub прості текстові конфлікти можна розв'язати в браузері через Resolve conflicts.
Приклад
Дві гілки змінили той самий рядок про безкоштовну доставку на сторінці Котокорму: одна на 800 грн, інша на 1000. Другий pull request повідомляє про конфлікт, команда домовляється про 1000, і Emma розв'язує його в браузері.
Типові помилки
Сприймати конфлікт як помилку, яку треба швидко прибрати. Це питання, на яке можуть відповісти лише люди; мердж без конфліктів теж може бути хибним, якщо дві зміни в різних файлах суперечать одна одній.
Вивчити в курсі
- Конфлікти під час мерджу: чому виникають і що робити · Чому дві гілки можуть зіткнутися на тому самому рядку, що тоді показує GitHub, як читати маркери конфлікту й розв'язати простий конфлікт у браузері і чому вибір правильного тексту це продуктове рішення.
- Іконки й кольори: що означає кожен стан · Читаємо pull requests, issues, перевірки, рев'ю, мітки й блок мерджу з першого погляду: що означає кожна іконка й колір GitHub і як розрізняти стани за формою й текстом, а не лише за кольором.
- Злиття: мердж-коміт, squash і rebase на GitHub · Що робить мердж, три варіанти за кнопкою мерджу на GitHub і що кожен лишає в історії, fast-forward простими словами і як перевірити, чи зміна справді в main.
- Анатомія pull request: вкладки, опис, перевірки · Читаємо сторінку pull request згори донизу: базова гілка й гілка змін, чернетка і готовий PR, чотири вкладки, опис, рев'юери й мітки, пов'язані issues, перевірки й блок мерджу.
- GitHub flow: малі гілки, швидкі мерджі · Цикл, у якому працює більшість продуктових команд: гілка від main, pull request, рев'ю й перевірки, мердж, деплой. Чому малі короткоживучі гілки безпечніші, що означають «змерджено» і «викладено», як фіча-флаги дають викласти незавершену роботу прихованою і як читати прогрес фічі зі списку pull requests.