Конфликты слияния в Git: короткое руководство
Git остановил слияние и пометил конфликтующие файлы? Разберём, как найти спорные строки, выбрать правильный вариант, завершить merge и отменить его, если вы зашли не туда. Команды подходят для Git 2.x.

Что понадобится до начала
За несколько минут вы сможете разрешить конфликт слияния в Git, проверить результат и завершить merge. Команды ниже рассчитаны на Git 2.x и обычное слияние веток из командной строки. Понадобятся открытый терминал, репозиторий и понимание того, чьи изменения должны остаться в спорных местах. Если не уверены в последнем пункте, не выбирайте вариант наугад.
- Убедитесь, что вы находитесь в нужном репозитории и ветке.
- Проверьте, нет ли незакоммиченных изменений: их можно случайно смешать с разрешением конфликта.
- Если работа командная, уточните у автора другой ветки смысл спорных изменений. Git сравнивает текст, но не знает намерений разработчиков.
1. Найдите причину остановки
Запустите слияние, указав имя ветки, изменения которой нужно внести в текущую:
git merge feature/search
Если Git не может автоматически объединить изменения, он остановит операцию и выведет список конфликтующих файлов. Проверьте состояние репозитория:
git status
В выводе ищите раздел Unmerged paths или сообщение о конфликтующих файлах. Зафиксируйте их список. Если в нём есть файл, который вы не ожидали менять, пока не продолжайте: сначала выясните, откуда пришли эти изменения.
2. Разберите конфликт в файле
Откройте каждый конфликтующий файл в редакторе. Git отмечает спорный участок специальными строками:
<<<<<<< HEAD
текущая версия
=======
версия из вливаемой ветки
>>>>>>> feature/search
В этом примере HEAD обозначает текущую ветку, а имя после разделителя внизу — вливаемую. Строка из семи знаков равенства разделяет варианты. Эти маркеры не являются частью программы: после разрешения конфликта их нужно удалить вместе с ненужным вариантом.
Выберите один вариант или объедините их вручную. Например, если одна ветка добавила проверку пустого запроса, а другая — запись результата в журнал, итоговый код может включать обе правки. Но включайте их вместе только если они совместимы по логике. Сохраните файл, затем повторите разбор для остальных конфликтов.
Git не выбирает, какая версия правильная. Он показывает место, где ваши изменения перестали быть совместимыми, а решение остаётся за вами.
3. Отметьте файлы и завершите слияние
После ручной правки Git не считает конфликт решённым, пока вы не добавите файл в индекс. Для одного файла выполните:
git add src/search.py
Повторите команду для каждого разрешённого файла. Затем проверьте состояние:
git status
В списке не должно оставаться неразрешённых конфликтов. Запустите подходящие проекту тесты или хотя бы проверьте изменённые файлы. Если проверки прошли, завершите merge:
git commit
Git откроет редактор с сообщением коммита слияния. Оставьте предложенный текст или уточните его, сохраните и закройте редактор. Успех можно проверить командой git status: рабочее дерево должно быть чистым, если других незакоммиченных изменений нет.
4. Если решение оказалось неверным
Пока слияние не завершено коммитом, его можно отменить:
git merge --abort
Команда возвращает репозиторий к состоянию до начала merge, когда это возможно. Если до слияния уже были незакоммиченные изменения, результат может зависеть от их состояния; поэтому проверка git status до начала важна. Не используйте отмену, если уже сделали коммит слияния: это другая ситуация, и безопасный способ отката зависит от того, отправили ли коммит в общий репозиторий.
Если не получилось
- «You have unmerged paths». Остались файлы с конфликтами. Откройте каждый из списка
git status, удалите маркеры, сохраните решение и добавьте файл черезgit add. - «Committing is not possible because you have unmerged files». Git не позволит создать коммит, пока остаётся неразрешённый файл. Проверьте все пути из
git status, включая те, о которых вы забыли. - Конфликтующие маркеры остались в файле. Возможно, вы удалили их не во всех местах. Найдите в редакторе строки с
<<<<<<<,=======и>>>>>>>, затем проверьте итоговый код. - После слияния тесты не проходят. Синтаксически аккуратное объединение не гарантирует правильной логики. Сравните поведение обеих веток и проверьте сценарий, который изменяли обе стороны.
Что делать дальше
Перед отправкой результата посмотрите итоговые изменения командой git diff HEAD^ HEAD после коммита: она покажет разницу между первым родителем и коммитом слияния. Затем запустите тесты проекта и отправьте merge в общий репозиторий по правилам команды. Если регулярно спорят одни и те же файлы, договоритесь об их владельцах или разбивайте крупные изменения на более короткие ветки.
Сноска. Индекс Git — промежуточная область, куда команда git add помещает выбранные изменения перед коммитом. В конфликте добавление файла означает: «Git, считать его текущую версию разрешением конфликта».
Слияние и разрешение конфликтов описаны в официальном руководстве Git. Поведение конкретного графического клиента может отличаться, но смысл конфликтных маркеров и необходимость отметить разрешённый файл остаются теми же.
Тест и проверочная: Быстрые ответы с объяснением, почему остальные варианты неверны
Спросить за 10 ₽Источники: Официальное руководство Git: Basic Merge Conflicts, Документация Git: git merge
Частые вопросы
Можно ли просто оставить свою версию файла?
Что делать, если конфликтов слишком много?
Я уже сделал коммит слияния, но выбрал неверный вариант. Что теперь?
Можно ли потерять незакоммиченные изменения при разрешении конфликта?
Нужно ли запускать тесты, если конфликт был только в одной строке?
Чем merge-конфликт отличается от конфликта при rebase?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.