AM
Разработка 8 мин чтения

Git merge conflict: как разрешить конфликт слияния

Пошаговое руководство по разрешению конфликтов слияния Git: маркеры конфликтов, команды git status/merge/abort, ручное редактирование,VS Code и GitHub.

Gitmergeконфликтконтроль версийGitHubmerge conflict

Симптомы

  • Git сообщает CONFLICT (content): Merge conflict в файле
  • В файле видны маркеры `<<<<<<<` , `=======` , `>>>>>>>`
  • Pull request не может быть слит из-за конфликтов
  • Ошибка Automatic merge failed; fix conflicts and then commit the result
  • git merge завершается ошибкой mid-merge
  • Файл показывает статус unmerged в git status

Возможные причины

  • Два разработчика изменили одни и те же строки в разных ветках
  • Один разработчик удалил файл, другой отредактировал его
  • Долгая работа без слияния с основной веткой (main/master)
  • Конфликт при cherry-pick коммитов между ветками
  • Конфликт при rebase на устаревшую ветку

Пошаговое решение

1

Проверьте статус конфликтов

Выполните git status для списка файлов с конфликтами. Git покажет секцию Unmerged paths с перечнем файлов, требующих разрешения. Каждый конфликтный файл будет помечен как both modified (оба ветки изменили) или deleted by us / deleted by them (одна ветка удалила). Это первый шаг — он покажет масштаб проблемы.

Команда 
git status
2

Просмотрите diffs между ветками

Перед редактированием изучите, что именно изменилось. Выполните git diff для просмотра текущих изменений, или git diff HEAD для diffs с последним коммитом. Команда git log --merge -p покажет diffs для конфликтующих коммитов. Это поможет понять контекст изменений с обеих сторон.

Команда 
git diff
3

Откройте файл и найдите маркеры конфликтов

Откройте конфликтный файл в текстовом редакторе. Ищите строку `<<<<<<<` — это начало конфликта. Все между `<<<<<<< HEAD` и `=======` — это изменения из текущей ветки. Все между `=======` и `>>>>>>> branch-name` — из вливаемой ветки. В VS Code конфликты подсвечиваются цветом и имеют кнопки Accept Current Change / Accept Incoming Change / Accept Both Changes прямо в коде.

4

Разрешите конфликт вручную

Удалите маркеры `<<<<<<<` , `=======` , `>>>>>>>` и оставьте нужный код. Варианты: (1) оставить только свою версию (Accept Current), (2) оставить только чужую (Accept Incoming), (3) объединить обе версии вручную, (4) написать новое решение. Важно: не оставляйте маркеры в коде — это вызовет ошибки при компиляции или работе приложения. После редактирования сохраните файл.

5

Добавьте разрешённые файлы в индекс

После редактирования каждого конфликтного файла добавьте его в staging area командой git add. Это сообщит Git, что конфликт разрешён для данного файла. Можно добавить все файлы разом: git add . — но лучше проверить каждый файл отдельно, чтобы не пропустить неразрешённые конфликты.

Команда 
git add .
6

Завершите слияние коммитом

Выполните git commit для завершения слияния. Git автоматически создаст merge commit с сообщением по умолчанию (Merge branch 'branch-name' into main). Можно написать своё сообщение: git commit -m "Resolve merge conflict: merged feature-auth into main". После этого ветка будет в слияном состоянии без конфликтов.

Команда 
git commit -m "Resolve merge conflict"
7

Используйте git merge --abort для отмены

Если конфликт слишком сложный или вы хотите начать заново, отмените слияние: git merge --abort. Это вернёт репозиторий в состояние до начала merge. Альтернатива: git reset --merge для сброса только staging area. После отмены можно обновить ветку (git pull origin main) и попробовать merge снова.

Команда 
git merge --abort
8

Разрешите конфликт удалённого файла

Если один разработчик удалил файл, а другой отредактировал, Git не может разрешить автоматически. Решение: (1) чтобы сохранить файл — git add <имя-файла>, (2) чтобы удалить — git rm <имя-файла>. После этого сделайте commit. Чтобы проверить, какой файл был удалён в какой ветке, выполните git log --diff-filter=D --summary.

Команда 
git rm filename.txt

Конфликт слияния (merge conflict) возникает, когда Git не может автоматически объединить изменения из двух веток. Это происходит, когда два разработчика изменили одни и те же строки файла или один удалил файл, а другой его отредактировал. Конфликт — это не ошибка, а штатная ситуация, требующая ручного разрешения.

Маркеры конфликтов в файле

При конфликте Git вставляет в файл специальные маркеры:

<<<<<<< HEAD
Этот код из текущей ветки (main)
=======
Этот код из вливаемой ветки (feature)
>>>>>>> feature-branch

Строка <<<<<<< HEAD обозначает начало конфликта. Всё до ======= — изменения из текущей ветки. Всё от ======= до >>>>>>> — из вливаемой. Ваша задача — удалить все три маркера и оставить итоговый код.

Когда возникают конфликты

Конфликт возникает при git merge, git pull, git rebase или git cherry-pick, если Git не может автоматически определить правильную версию. Типичные сценарии: оба разработчика изменили одну строку, один добавил код в конец файла, другой — в начало, один переименовал функцию, другой вызвал её по старому имени.

Команды для диагностики

git status — список конфликтующих файлов. git diff — что именно изменилось. git log --merge -p — diffs для конфликтующих коммитов. git diff AUTO_MERGE — что уже разрешено. git show :1:filename — общая база, git show :2:filename — HEAD версия, git show :3:filename — MERGE_HEAD версия.

Отмена слияния

Если конфликт слишком сложный — git merge --abort вернёт всё как было. git reset --merge сбросит staging area. Это безопасные команды, не затрагивающие коммиты.

Источники

  1. docs.github.com — проверено 02.06.2026
  2. atlassian.com — проверено 02.06.2026
  3. github.com — проверено 02.06.2026
  4. docs.github.com — проверено 02.06.2026
  5. git-scm.com — проверено 02.06.2026