Пошук уроків, статей та іншого контенту
Що робити, коли Git не може автоматично об'єднати зміни двох гілок — маркери конфлікту та ручне рішення.
Конфлікт злиття виникає, коли обидві гілки змінили ті самі рядки того самого файлу по-різному — Git не має способу автоматично вирішити, яка з двох версій правильна, і зупиняє злиття, залишаючи файл у проміжному стані з обома варіантами, позначеними спеціальними маркерами, для ручного вирішення людиною.
function getGreeting(name) {
<<<<<<< HEAD
return `Привіт, ${name}!`;
=======
return `Вітаємо, ${name}!`;
>>>>>>> feature/friendly-greeting
}<<<<<<< HEAD — початок версії з поточної гілки (куди зливають).
======= — розділювач між двома конфліктними версіями.
>>>>>>> feature/friendly-greeting — кінець версії з гілки, яку зливають, з її іменем.
Розробник відкриває файл, вирішує, яку версію лишити (одну з двох, обидві поєднані, чи повністю новий варіант), видаляє маркери конфлікту вручну, зберігає файл — після чого файл додають у staging area й завершують злиття звичайним комітом:
// Після ручного вирішення — маркери видалені, лишилась одна фінальна версія:
function getGreeting(name) {
return `Вітаємо, ${name}!`;
}git add index.js # позначити конфлікт вирішеним для цього файлу
git commit # завершити злиття комітом (повідомлення вже підготовлене Git)Під час незавершеного злиття з конфліктом git status явно перелічує файли з невирішеними конфліктами окремо від файлів, злитих автоматично, — корисний орієнтир, коли конфліктних файлів кілька.
Якщо вирішення конфлікту виявилось надто заплутаним чи помилковим, злиття можна повністю скасувати й почати заново — git merge --abort повертає репозиторій у стан до початку злиття, ніби команда git merge ніколи не викликалась.
Практичний спосіб зменшити кількість і складність конфліктів — регулярно зливати main у свою feature-гілку під час довгої роботи (git merge main, перебуваючи на feature-гілці), а не лише один раз наприкінці. Дрібні, часті злиття з невеликою різницею між гілками конфліктують значно рідше й простіше, ніж одне велике злиття місяців розбіжної роботи.
Забути видалити маркери конфлікту (<<<<<<<, =======, >>>>>>>) перед комітом — файл із маркерами, що лишились, комітиться як синтаксично зламаний код.
Панічно вирішувати конфлікт навмання, не розуміючи логіки обох версій, — краще звернутись до автора іншої зміни чи детально прочитати обидва варіанти, ніж вибрати випадково й отримати регресію.
Уникати регулярного злиття main у довгоживучу feature-гілку — накопичує розбіжність, що робить фінальне злиття значно більшим і складнішим конфліктом, ніж кілька дрібних по дорозі.
Конфлікт злиття виникає, коли обидві гілки по-різному змінили ті самі рядки файлу — Git позначає обидві версії маркерами (<<<<<<<, =======, >>>>>>>) для ручного вирішення. Після видалення маркерів і вибору фінальної версії файл додають у staging area й завершують злиття звичайним комітом; git merge --abort скасовує злиття повністю, якщо потрібно почати заново. Регулярне, часте злиття main у довгоживучу гілку — практичний спосіб тримати конфлікти дрібними й керованими.