Конфликты слияния в Git: частые ошибки новичков

Конфликт слияния в Git обычно появляется, когда две ветки изменили одну и ту же часть файла. За несколько минут можно увидеть, что именно не сошлось, собрать нужный итоговый вариант и завершить операцию — или безопасно отменить её. Ниже — команды для Git 2.x; перед началом проверьте, что понимаете, какая ветка и какая операция сейчас активны.

Что нужно до начала

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

Полезно знать два термина. Рабочая копия — файлы проекта, которые вы видите и редактируете. Индекс* — подготовленная область Git: именно из неё создаётся следующий коммит.

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

1. Проверьте состояние репозитория. Выполните команду в каталоге проекта:

   git status

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

2. Откройте конфликтный файл. Найдите в нём маркеры конфликта:

   <<<<<<< HEAD
   текущая версия строки
   =======
   версия из вливаемой ветки
   >>>>>>> feature

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

3. Соберите итоговый текст. Оставьте нужные строки из одного блока, объедините изменения или перепишите фрагмент так, чтобы он работал вместе. Удалите все маркеры: Git не удалит их за вас. Если смысл изменений непонятен, сравните файл с обеими ветками или спросите автора изменений до редактирования. Проверка: в файле нет строк <<<<<<<, ======= и >>>>>>>.

4. Добавьте исправленный файл в индекс. Для одного файла:

   git add путь/к/файлу

   Замените пример на реальный путь из вывода git status. Эта команда сообщает Git, что конфликт в файле разрешён. Проверка: повторный git status больше не показывает этот файл как неразрешённый.

5. Завершите операцию. Сначала снова проверьте статус. При слиянии команда git merge --continue завершает слияние; если Git предложит создать коммит или сообщит, что коммит уже создан, следуйте этому сообщению. При перебазировании используйте git rebase --continue только если статус подтверждает, что идёт перебазирование. Проверка: статус больше не говорит о незавершённой операции, а история содержит ожидаемый результат.

6. Проверьте проект. Запустите тесты или сборку, предусмотренные проектом, и просмотрите итоговый diff:

   git diff HEAD

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

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

Частые ошибки новичков

Оставить маркеры в файле

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

Выбрать целиком одну сторону

Команды и кнопки с названиями вроде «принять текущую» и «принять входящую» полезны, когда выбор очевиден. Но они могут удалить нужное изменение из другой ветки. Не ориентируйтесь только на слова «текущая» и «входящая»: при перебазировании смысл сторон отличается от обычного слияния. После выбора прочитайте весь получившийся фрагмент.

Считать, что git add исправил файл

git add отмечает разрешённый файл как готовый для продолжения операции. Он не редактирует содержимое и не проверяет его корректность. Если добавить файл с маркерами, Git может принять его как разрешённый, но дефект останется в проекте.

Запустить не ту команду продолжения

git merge --continue и git rebase --continue относятся к разным операциям. Ошибка здесь часто начинается с того, что человек не прочитал git status. Ориентируйтесь на состояние репозитория и подсказки Git, а не на команду из чужого ответа.

Отменить операцию, не разобравшись в изменениях

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

Если Git показывает ошибку

• «You have unmerged paths». Есть файлы, которые ещё не разрешены. Откройте список в git status, исправьте каждый файл и добавьте его через git add.

• «needs merge». Git обнаружил неразрешённый файл. Не пытайтесь завершить операцию раньше, чем уберёте конфликт и отметите файл разрешённым.

• «There is no merge in progress». Незавершённого слияния нет. Возможно, вы выполняли rebase или операция уже завершилась. Снова проверьте git status.

• После исправления Git всё ещё сообщает о конфликте. Проверьте, что отредактировали именно файл из списка конфликтов и выполнили git add для актуального пути. Затем повторите git status.

Что проверить перед отправкой изменений

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

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

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

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

* Индекс Git (staging area) — список изменений, которые попадут в следующий коммит. Команда git add помещает туда выбранный файл.