Что является результатом git merge

Что проверяют

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

Как отвечать

Результат зависит от взаимного расположения веток.

Если текущая ветка это прямой предок сливаемой, происходит перемотка: указатель переставляется вперёд, новых коммитов не появляется. Флаг --no-ff заставляет сделать коммит слияния даже здесь, и многие команды его включают, чтобы ветка задачи осталась видна в истории.

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

Если сливаемая ветка уже содержится в текущей, не меняется ничего.

Отдельный случай это конфликт. Репозиторий остаётся в незавершённом состоянии: в индексе лежат три версии файла, в рабочем дереве маркеры, ссылка на сливаемую вершину сохранена отдельно. Выход или через разрешение и завершение слияния, или через отмену.

git merge --abort           # вернуться к состоянию до слияния
git merge --squash feature  # изменения без коммита и без второго родителя

Где спотыкаются

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

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

Забывают, что содержимое коммита слияния никто не проверяет. Собранный руками файл может вообще не запускаться: в питоновом проекте это обычно склеенный файл блокировки зависимостей или две ветки миграций, которые формально слились, а цепочка ревизий разошлась и чинится отдельной командой слияния миграций.