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

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

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

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

Основное различие - в том, как интегрируются изменения и что происходит с историей.

Merge:

• создаёт новый коммит (merge commit) с двумя родителями
• сохраняет полную историю обеих веток, включая все промежуточные коммиты
• не изменяет существующие коммиты - их хеши остаются прежними
• история становится нелинейной, но полностью отражает реальный ход разработки

Rebase:

• берёт коммиты из вашей ветки и "перекладывает" их поверх целевой ветки
• каждый переносимый коммит получает новый хеш, даже если содержимое не изменилось
• история становится линейной - выглядит так, будто вы работали последовательно
• переписывает историю, что опасно для общих веток: если кто-то уже забрал ваши коммиты, у него будут конфликты при следующем pull

Ключевой trade-off: rebase даёт чистую историю, но ломает синхронизацию у других разработчиков. Merge сохраняет контекст, но создаёт "шум" из merge-коммитов.

На практике

В мобильной разработке (iOS, Swift) обычно используют следующий подход:

• для личных feature-веток - rebase перед merge, чтобы получить линейную историю
• для общих веток (develop, main) - только merge, чтобы не переписывать публичную историю
• при работе с Pull Request - часто используют squash merge, который объединяет все коммиты ветки в один

Частая практика в командах: git pull --rebase вместо git pull, чтобы избежать лишних merge-коммитов при синхронизации с удалённой веткой.

Пример кода

BASH
# Merge: интегрируем feature в main
git checkout main
git merge feature
# создаётся merge commit

# Rebase: переносим коммиты feature поверх main
git checkout feature
git rebase main
# коммиты feature пересоздаются поверх main

# Затем fast-forward merge для линейной истории
git checkout main
git merge feature
# без merge commit, просто указатель перемещается

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

Начните с краткого определения, затем переходите к ключевым различиям: создание merge commit vs переписывание истории. Обязательно упомяните последствия для хешей коммитов и почему rebase опасен для общих веток. Приведите пример из практики: как вы работаете с feature-ветками в iOS-проекте. Покажите понимание trade-off: чистая история vs сохранение контекста. Если спросят про конфликты - отметьте, что при rebase конфликты решаются по одному коммиту, а при merge - один раз.

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

• понимание модели коммитов Git и того, как хранится история
• знание последствий переписывания истории для командной работы
• умение выбирать инструмент под конкретную ситуацию
• практический опыт работы с ветками в реальных проектах
• понимание workflow в команде: когда rebase уместен, а когда нет

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

• утверждение, что rebase "лучше" merge без контекста - это не так, всё зависит от ситуации
• игнорирование опасности rebase для публичных веток - главный подводный камень
• путаница между rebase и squash merge - это разные операции
• непонимание, что rebase меняет хеши коммитов, даже если содержимое идентично
• рекомендация использовать rebase для общих веток без оговорок - грубая ошибка для senior
• забывают упомянуть git pull --rebase как практический приём для избежания лишних merge-коммитов