Как решить конфликт при слиянии в Git: подробное руководство

Работа с Git часто напоминает попытку договориться с упрямым собеседником — кажется, вы всё сделали правильно, но система упорно отказывается принимать изменения. Особенно это чувствуется, когда после нескольких часов работы над кодом вы видите предательское сообщение «Updates were rejected» при попытке отправить изменения на сервер. Давайте разберёмся, как превратить этот диалог в продуктивное сотрудничение.

Почему Git отказывается принимать изменения и как это исправить

Представьте: вы сделали два новых коммита в локальной ветке development, проверили статус через git status — всё чисто. Но при попытке git push получаете ошибку:

! [rejected] development -> development (fetch first)

Что происходит? Гит вежливо намекает, что пока вы работали, кто-то уже обновил удалённую ветку. Система не может просто «перезаписать» историю — это привело бы к потере чужих изменений.

Здесь поможет классический алгоритм:

1. Выполните git pull, чтобы скачать обновления с сервера.
2. Разрешите возможные конфликты (если они есть).
3. Снова запушите изменения.

Но именно на втором шаге многие спотыкаются. После git pull вы можете увидеть редактор (чаще всего Vim) с сообщением:

# Lines starting with '#' will be ignored, and an empty message aborts the commit.

Важно: даже если вы закроете редактор без комментария, Git не отменит операцию — вы останетесь в состоянии слияния. Чтобы выйти «без потерь»:

• Нажмите i для перехода в режим редактирования.
• Введите сообщение о слиянии (например, «Merge remote changes»).
• Нажмите Esc, затем введите :wq и Enter для сохранения.

Если конфликтов не было, Git автоматически создаст коммит слияния. Теперь git push сработает без ошибок.

Когда отдельная ветка спасает от хаоса

Работать напрямую в development — всё равно что готовить ужин на общей кухне, где другие повара постоянно меняют рецепт. Гораздо безопаснее создать персональную ветку для своих задач.

Пошаговый рецепт:

1. Обновите основную ветку:
   

   git checkout development
   git pull origin development

2. Создайте новую ветку:
   

   git checkout -b feature/my-awesome-changes

3. Работайте в своей ветке, делайте коммиты, тестируйте — здесь вы никому не мешаете.
4. Когда всё готово:
   

   git push origin feature/my-awesome-changes

5. Создайте Pull Request через GitHub/GitLab — так команда сможет проверить ваши изменения перед слиянием.

Зачем это нужно?

• Вы избегаете конфликтов при обновлении development.
• Легко откатываться к стабильной версии.
• История коммитов остаётся чистой и логичной.

Бонус: как читать вывод git pull

После слияния Git показывает список обновлённых веток:

7948726..7dc3f5c  development     -> origin/development
b9042ed..d04db55  feature/luxor   -> origin/feature/luxor

Расшифровка:

• 7948726..7dc3f5c — диапазон коммитов (от старого хэша к новому).
• development -> origin/development — локальная ветка синхронизирована с удалённой.

Если видите подобное в production — это повод проверить, не попали ли туда случайно ваши изменения.

Практический совет напоследок: Если Vim кажется слишком сложным, смените редактор по умолчанию. Например, для VS Code:

git config --global core.editor "code --wait"

Теперь при слияниях будет открываться привычный интерфейс. Главное — не забывайте сохранять файл перед закрытием!

Сталкивались с похожими ситуациями? Делитесь в комментариях — возможно, ваш опыт поможет другим преодолеть «гитовский» ступор.