В чём разница между merge и rebase?

merge и rebase — два способа интегрировать изменения из одной ветки в другую. Они дают одинаковый результат (объединённый код), но различаются тем, как выглядит история коммитов.

Аналогия из жизни: merge — это вклеить вставку с правками между страницами книги (видно, что была вставка). rebase — это переписать страницы набело, будто правки были изначально (чистая линейная история, но оригинал утрачен).

Merge (слияние)

Создаёт новый merge-коммит, объединяющий две ветки. Сохраняет полную историю ветвления.

До merge:
main:    C1 -- C2 -- C3
                \
feature:         C4 -- C5

После git merge feature:
main:    C1 -- C2 -- C3 -- M (merge commit)
                \         /
feature:         C4 -- C5

git switch main
git merge feature/auth
# Создаётся merge-коммит M

# Merge без fast-forward (всегда создаёт merge-коммит)
git merge --no-ff feature/auth

# Squash merge — объединить все коммиты ветки в один
git merge --squash feature/auth
git commit -m "feat: добавлена авторизация"

Rebase (перебазирование)

Переносит коммиты ветки на вершину другой ветки, создавая линейную историю. Фактически заново применяет каждый коммит.

До rebase:
main:    C1 -- C2 -- C3
                \
feature:         C4 -- C5

После git rebase main (находясь в feature):
main:    C1 -- C2 -- C3
                       \
feature:                C4' -- C5'

# Перебазировать feature на main
git switch feature/auth
git rebase main

# После rebase — обычный fast-forward merge
git switch main
git merge feature/auth

Interactive Rebase

Позволяет изменять коммиты перед перебазированием:

# Интерактивный rebase последних 3 коммитов
git rebase -i HEAD~3

В редакторе доступны действия:

• pick — оставить коммит как есть
• reword — изменить сообщение коммита
• squash — объединить с предыдущим коммитом (сохранить сообщение)
• fixup — объединить с предыдущим (отбросить сообщение)
• drop — удалить коммит

Сравнение

Золотое правило rebase

Никогда не перебазируйте коммиты, которые уже были отправлены в публичный (shared) репозиторий.

Rebase изменяет SHA-1 хеши коммитов, что приводит к проблемам у других разработчиков, работающих с теми же ветками.

# ОПАСНО: rebase ветки, которая уже запушена и с которой работают другие
git rebase main   # коммиты получат новые хеши
git push --force  # перезаписывает историю на сервере — сломает работу коллегам!

# БЕЗОПАСНО: rebase локальной ветки, которую ещё не пушили
git switch feature/local-work
git rebase main

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

• merge безопасен всегда. rebase безопасен только для локальных (не опубликованных) коммитов
• merge --squash — хороший компромисс: один чистый коммит без merge-коммита и без переписывания истории
• Interactive rebase — мощный инструмент для приведения локальной истории в порядок перед push
• Команды часто используют rebase для обновления feature-ветки и merge для интеграции в main

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

• Использовать rebase на ветках, с которыми работают другие разработчики
• Использовать git push --force после rebase на shared-ветке — потеря чужих коммитов
• Путать merge --squash и rebase --squash (squash — это опция interactive rebase, не отдельная команда)
• Не делать git pull --rebase при обновлении — получать лишние merge-коммиты

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

• Многие команды используют rebase для feature-веток и merge --squash или merge --no-ff для интеграции в main
• GitHub и GitLab предлагают выбор стратегии merge при закрытии PR: merge commit, squash and merge, rebase and merge
• git pull --rebase часто устанавливают по умолчанию через git config --global pull.rebase true
• git push --force-with-lease вместо --force — более безопасный вариант, проверяющий, что remote не изменился

На собеседовании: это один из самых частых вопросов. Покажите понимание золотого правила: rebase — только для локальных коммитов. Хороший ответ включает сравнительную таблицу и упоминание merge --squash как компромисса. Интервьюер может попросить нарисовать графы до и после merge/rebase.