Как разрешить конфликт при merge/rebase?

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

Аналогия из жизни: два редактора одновременно правят один и тот же абзац статьи. Когда правки нужно объединить, редактор-координатор (вы) должен решить, чью версию оставить или как совместить обе.

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

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

public class UserService {
<<<<<<< HEAD
    private final AuthService authService;
    private final UserRepository userRepo;
=======
    private final AuthenticationService authService;
    private final UserDAO userDao;
>>>>>>> feature/refactor-auth
}

• <<<<<<< HEAD — начало изменений из текущей ветки
• ======= — разделитель
• >>>>>>> feature/... — конец изменений из вливаемой ветки

Процесс разрешения конфликта при merge

# 1. Начинаем merge
git merge feature/auth
# CONFLICT (content): Merge conflict in src/UserService.java

# 2. Смотрим, какие файлы конфликтуют
git status
# both modified: src/UserService.java

# 3. Открываем файл и вручную редактируем — убираем маркеры, оставляем нужный код

# 4. Добавляем исправленные файлы
git add src/UserService.java

# 5. Завершаем merge
git commit
# Git автоматически подставит сообщение о merge

Процесс разрешения конфликта при rebase

# 1. Начинаем rebase
git rebase main
# CONFLICT in src/UserService.java

# 2. Разрешаем конфликт в файле

# 3. Добавляем исправленный файл
git add src/UserService.java

# 4. Продолжаем rebase (НЕ commit!)
git rebase --continue

# Если возникнут конфликты в следующем коммите — повторяем шаги 2-4

Отмена merge/rebase

# Отменить merge (вернуться к состоянию до merge)
git merge --abort

# Отменить rebase (вернуться к состоянию до rebase)
git rebase --abort

Использование mergetool

# Запустить визуальный инструмент для разрешения конфликтов
git mergetool

# Настроить инструмент по умолчанию
git config --global merge.tool vimdiff
# Или для IntelliJ IDEA:
git config --global merge.tool intellij

Стратегии выбора при конфликте

# Принять все изменения из нашей ветки
git checkout --ours src/UserService.java

# Принять все изменения из вливаемой ветки
git checkout --theirs src/UserService.java

Ключевые моменты

• При rebase конфликт может возникать на каждом коммите (так как коммиты применяются по одному), при merge — один раз
• Команда git rebase --continue продолжает rebase после разрешения конфликта. Не используйте git commit при rebase
• Использование --ours и --theirs полностью заменяет файл одной из версий — используйте аккуратно
• Всегда проверяйте результат разрешения конфликта — компиляция и тесты должны проходить

Частые ошибки

• Оставлять маркеры конфликта (<<<<, ====, >>>>) в коде — файл не скомпилируется
• Использовать git commit вместо git rebase --continue при разрешении конфликта во время rebase
• Принимать «свою» версию целиком без анализа — можно потерять чужие изменения
• Не запускать тесты после разрешения конфликтов

Как используется в 2026

• IDE (IntelliJ IDEA, VS Code) предоставляют удобный трёхпанельный интерфейс для разрешения конфликтов
• AI-ассистенты помогают анализировать и предлагать варианты разрешения конфликтов
• Merge queues в GitHub/GitLab автоматически перебазируют и проверяют ветки перед merge, минимизируя конфликты
• Частые маленькие PR и trunk-based development снижают вероятность конфликтов

На собеседовании: интервьюер проверяет практический опыт. Опишите пошаговый процесс: увидеть конфликт в git status, открыть файл, убрать маркеры, git add, git commit (merge) или git rebase --continue (rebase). Упомяните --abort для отмены и что при rebase конфликты могут возникать на каждом коммите.