Почему в Git появляется конфликт слияния — и как его убрать

Ты сливаешь ветки или делаешь git pull, и терминал выдаёт CONFLICT (content): Merge conflict in app.js, а слияние замирает на полпути. Первая реакция — «я всё сломал». Нет. Конфликт слияния — это не ошибка и не поломка. Это Git честно говорит: «два изменения спорят за одно место, и я не хочу решать за тебя». Разберём, почему так выходит и как это спокойно разрулить.

Симптом: что именно ты видишь

Git останавливает слияние и помечает проблемные файлы. Внутри такого файла появляются маркеры:

<<<<<<< HEAD
твоя версия строки
=======
версия из другой ветки
>>>>>>> feature-branch

Между <<<<<<< и ======= — твой вариант, между ======= и >>>>>>> — чужой. Git не выбрал сам, потому что оба меняли одно место. Причин, почему это случилось, обычно три.

Причина 1: обе ветки правили одни и те же строки

Самый частый случай. Ты в своей ветке поменял строку 10, а в main кто-то (или ты сам раньше) поменял ту же строку 10 по-другому. При слиянии Git видит два разных варианта одной строки и не знает, какой правильный.

Как проверить: запусти git status — он покажет файлы с пометкой both modified. Именно в них лежат маркеры конфликта.

Причина 2: файл удалён в одной ветке, изменён в другой

Хитрый вариант. В одной ветке файл удалили, а в другой — правили. Git не знает, что важнее: сохранить твои правки или уважить удаление.

Как проверить: в git status увидишь формулировку вроде deleted by them или deleted by us. Здесь конфликт не про строки, а про судьбу всего файла — решаешь, оставить его или удалить.

Причина 3: pull поверх незакоммиченных правок

Ты правил файл, не закоммитил, и сделал git pull — а там прилетели чужие изменения того же файла. Git пытается наложить одно на другое и упирается в конфликт.

Как проверить: вспомни, коммитил ли ты перед pull. Привычка «сначала коммит, потом pull» убирает половину таких случаев. Кстати, если наоборот — push отклоняется, это отдельная история.

Как разрешить конфликт по шагам

Механика одна для всех трёх причин:

1. Открой файл, найди маркеры <<<<<<<, =======, >>>>>>>.
2. Реши, как должна выглядеть строка: оставь свой вариант, чужой, или собери из обоих.
3. Удали сами маркеры — все три строки с <, =, >. Это забывают чаще всего, и потом код падает из-за мусора в файле.
4. Сохрани файл, потом git add <файл> — так ты говоришь «этот конфликт улажен».
5. Когда все файлы улажены — git commit, чтобы завершить слияние.

Всё. Слияние доведено до конца, история цела.

Вопрос: можно ли отменить слияние и подумать?

Да, и это часто разумно. git merge --abort откатывает всё в состояние до слияния, будто ты и не начинал. Никакой спешки: прервал, разобрался спокойно, попробовал снова. Полезные команды рядом — в шпаргалке для новичка.

Вопрос: как ловить конфликты пореже?

Три привычки: коммить чаще и мелкими порциями; почаще подтягивай main в свою ветку, чтобы не расходиться далеко; и держи одну задачу в одной ветке, а не правь пол-проекта разом. Конфликты не исчезнут совсем — это нормальная часть работы, — но станут редкими и мелкими.