> В чем разница между git rebase и merge (Python)

Короткий ответ

git merge создаёт merge commit, сохраняя историю веток как есть, а git rebase переписывает историю, перенося коммиты одной ветки на вершину другой. Merge не изменяет существующие коммиты, rebase - изменяет их хеши и авторов. Merge безопаснее для общей ветки, rebase даёт линейную историю, но требует force push при публикации.

Подробное объяснение

Основное различие - в модели работы с историей коммитов.

git merge берёт две ветки и объединяет их в один новый коммит с двумя родителями. История остаётся полной: видны все коммиты обеих веток, их параллельное развитие и точка слияния. Merge не трогает существующие коммиты, поэтому не возникает конфликтов с уже опубликованной историей.

git rebase берёт коммиты текущей ветки, "отрезает" их от общего предка и накладывает поверх актуальной вершины целевой ветки. Каждый переносимый коммит создаётся заново - с новым родителем, новым хешем и, если настроено, новым автором. История становится линейной, без merge commit.

Ключевые trade-off:

• Безопасность: merge не переписывает историю, rebase - переписывает. Если ветка уже опубликована в remote и кто-то её забрал, rebase сломает их локальные копии.
• Читаемость: rebase даёт чистую линейную историю, удобную для code review и git bisect. Merge сохраняет контекст "когда и где велась параллельная работа".
• Конфликты: при rebase конфликты разрешаются на каждом коммите отдельно, при merge - один раз в merge commit. Rebase может потребовать повторного разрешения одного и того же конфликта несколько раз.
• Интерактивный режим: git rebase -i позволяет переупорядочивать, объединять и редактировать коммиты перед переносом - merge такого не умеет.

На практике в командах обычно используют обе операции: rebase для локальных feature-веток перед merge, merge (или squash merge) для интеграции в общую ветку.

На практике

Для backend-разработчика на Python типичный сценарий:

1. Создал feature-ветку от main.
2. Пока работал, в main влили чужие изменения.
3. Нужно обновить свою ветку - здесь выбор между merge и rebase.

Если ветка только локальная - rebase даст чистую историю перед PR. Если ветка уже в remote и над ней работают другие - только merge.

Для командной работы часто используют git merge --squash или squash через GitHub/GitLab: все коммиты feature-ветки схлопываются в один, история main остаётся линейной без merge commit.

Важно помнить про git pull --rebase - это стандартный способ синхронизации локальной ветки с remote без создания лишних merge commit.

Пример кода

BASH
# Merge: создаёт merge commit
git checkout feature
git merge main

# Rebase: переносит коммиты feature на вершину main
git checkout feature
git rebase main

# Интерактивный rebase: переупорядочить, squash, edit
git rebase -i HEAD~3

# Отмена rebase, если что-то пошло не так
git rebase --abort

# После rebase опубликованной ветки - force push
git push --force-with-lease origin feature

Как отвечать на собеседовании

Начни с короткого определения: merge - это слияние с сохранением истории, rebase - переписывание истории с переносом коммитов. Затем переходи к практическим последствиям: хеши коммитов, force push, конфликты.

Обязательно упомяни сценарии использования: rebase для локальных веток и чистоты истории, merge для общих веток и сохранения контекста. Если спросят про --force-with-lease - объясни, почему это безопаснее --force.

Хорошо показать понимание того, что rebase и merge решают разные задачи, а не являются взаимоисключающими. Можно упомянуть git pull --rebase как повседневную практику.

Что проверяет интервьюер

Интервьюер оценивает:

• понимание модели коммитов и родителей в git;
• знание последствий переписывания истории;
• умение выбирать инструмент под конкретную ситуацию;
• осведомлённость о работе в команде (force push, shared branches);
• знание интерактивного режима rebase.

Для senior-позиции важно не просто перечислить отличия, а показать, как это влияет на процесс разработки, code review и отладку.

Типичные ошибки

• Утверждение, что rebase "лучше" merge - без контекста это неверно.
• Забывают упомянуть, что rebase меняет хеши коммитов.
• Не знают про --force-with-lease и предлагают обычный --force.
• Путают git rebase и git merge --squash.
• Не упоминают, что конфликты при rebase могут повторяться на каждом коммите.
• Считают, что rebase удаляет коммиты - на самом деле он их пересоздаёт.