Разрешение конфликтов слияния в Git: пошаговая инструкция

За 10–20 минут вы сможете разрешить обычный конфликт слияния в Git 2.44 и новее: найти спорные файлы, вручную выбрать нужный код, проверить результат и завершить merge. Инструкция рассчитана на ситуацию, когда Git остановил слияние после команды git merge и сообщил о конфликте.

Что нужно иметь до начала

Понадобятся установленный Git 2.44 или новее, локальная копия репозитория и незакоммиченные изменения только в тех файлах, которые вы осознанно хотите сохранить. Проверьте версию и состояние рабочей директории:

git --version
git status

Перед началом сохраните незакоммиченные изменения: закоммитьте их или временно уберите в stash. Не запускайте слияние поверх незавершённой работы без понимания последствий: так сложнее отличить старые изменения от результата merge.

Проверка: команда git status показывает понятное состояние, а версия Git начинается с 2.44 или выше.

Конфликт слияния — ситуация, в которой Git не может автоматически объединить изменения, потому что две ветки затронули один и тот же участок файла или одна из них изменила файл, который другая удалили.

Пошаговое разрешение конфликта

1. Перейдите в ветку, куда нужно влить изменения. Например, если вы добавляете feature в main, выполните:

   git switch main
   git pull --ff-only

   Команда git pull --ff-only обновляет локальную ветку только без создания неожиданного merge-коммита. Проверка: git status сообщает, что вы на ветке main и рабочая директория чистая.

2. Запустите слияние.

   git merge feature

   Если Git не смог завершить операцию, он перечислит конфликтующие файлы и оставит слияние незавершённым. Проверка: в выводе есть сообщение о конфликте, а git status показывает секцию Unmerged paths.

3. Получите список всех конфликтующих файлов.

   git status

   Не ограничивайтесь первым файлом из сообщения Git: конфликтов может быть несколько, включая конфликт удаления и изменения. Проверка: вы выписали все файлы со статусами both modified, both added, deleted by us или deleted by them.

4. Откройте спорный файл и найдите маркеры Git.

   <<<<<<< HEAD
   код из текущей ветки
   =======
   код из ветки feature
   >>>>>>> feature

   Строки между <<<<<<< HEAD и ======= относятся к текущей ветке, а строки между ======= и >>>>>>> feature — к вливаемой. Оставьте рабочий вариант: одну сторону, обе части в правильном порядке или собственную комбинацию, затем удалите все три группы маркеров. Проверка: поиск по файлу не находит <<<<<<<, ======= и >>>>>>>.

5. Проверьте конфликтные изменения до добавления файла. Посмотрите, что именно Git считает неразрешённым:

   git diff --check
   git diff

   Первая команда помогает найти лишние пробелы и другие ошибки форматирования, вторая показывает незавершённый результат слияния. Проверка: в изменённых файлах нет маркеров конфликта, случайно удалённых строк и обрезанных блоков.

6. Отметьте исправленные файлы. Для каждого файла, который вы проверили, выполните:

git add path/to/file

Замените path/to/file на реальный путь, например src/config.js. Команда git add не исправляет файл, а сообщает Git: «этот конфликт решён, включи текущую версию в результат слияния». Проверка: повторный git status больше не показывает этот файл в Unmerged paths.

1. Убедитесь, что конфликтов не осталось.

   git status
   git diff --cached --check

   Если все файлы добавлены, Git предложит завершить merge. Проверка: в статусе нет секции Unmerged paths, а проверка индекса не сообщает об ошибках.

2. Запустите тесты проекта. Универсальной команды для всех проектов нет: используйте принятую в репозитории команду, например npm test, pytest или ./gradlew test. Проверка: тесты завершаются без ошибок, а вручную проверенный сценарий не потерял поведение ни одной из веток.

3. Завершите слияние.

   git commit

   Git откроет редактор с подготовленным сообщением merge-коммита. Сохраните его или отредактируйте так, чтобы было понятно, какие ветки объединены. Проверка: git status сообщает, что рабочая директория чистая, а команда git log --oneline --graph -5 показывает новый коммит слияния.

Главное решение при конфликте — не «левая или правая версия», а проверка того, какое поведение должно остаться в приложении после объединения.

Когда лучше отменить слияние

Если конфликтов слишком много, вы не понимаете назначение изменений или начали merge не той ветки, не пытайтесь ставить случайные маркеры. Вернитесь к состоянию до операции:

git merge --abort

Команда отменяет незавершённое слияние, если Git ещё хранит его состояние. Проверка: git status больше не сообщает о merge в процессе. Если команда не сработала, не удаляйте файлы вручную: сначала сохраните важные изменения и изучите вывод git status.

Типичные ошибки и что с ними делать

«You have unmerged paths»

Один или несколько файлов ещё не отмечены как решённые. Откройте список через git status, исправьте каждый файл и выполните git add для каждого из них.

«The following untracked working tree files would be overwritten»

В рабочей директории есть неотслеживаемые файлы, которые merge может перезаписать. Переместите их в безопасное место, добавьте в репозиторий или удалите только после проверки содержимого, затем повторите слияние.

После разрешения тесты падают

Git проверяет синтаксическое объединение, а не смысл программы. Сравните итоговый файл с обеими ветками, проверьте импорты, конфигурацию и миграции. Если ошибка появилась после нескольких правок, отмените merge и повторите его меньшими шагами вместе с владельцем кода.

«MERGE_HEAD exists»

Предыдущее слияние ещё не завершено. Если вы хотите продолжить, вернитесь к списку конфликтов и закончите операцию. Если merge был ошибочным, используйте git merge --abort.

Выбор одной стороны: только когда вы уверены

Иногда файл нужно целиком оставить из одной ветки. Во время merge команда --ours выбирает версию текущей ветки, а --theirs — версию вливаемой ветки:

git checkout --ours path/to/file
git add path/to/file

Или:

git checkout --theirs path/to/file
git add path/to/file

Этот способ опасен для конфигураций, миграций и больших исходных файлов: вместе с конфликтом можно незаметно выбросить полезные изменения. После выбора всё равно откройте файл и запустите тесты.

Что делать дальше

После успешного merge проверьте историю командой git log --oneline --graph --decorate -10, отправьте результат в удалённый репозиторий и попросите коллегу посмотреть именно разрешённые участки. Для следующего конфликта полезно заранее договориться о формате изменений, чаще синхронизировать долгоживущие ветки и проверять merge в отдельной рабочей копии. Если конфликты повторяются в одном файле, вынесите его назначение и правила изменения в документацию проекта.