Git rebase vs merge: когда и как правильно выбирать

Введение

Git предоставляет два основных способа интеграции изменений из одной ветки в другую: merge и rebase. Оба решают одну задачу, но делают это по-разному, и выбор между ними напрямую влияет на чистоту истории репозитория и удобство работы в команде.

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

Как работает git merge

Команда git merge объединяет две ветки, создавая новый коммит слияния — merge commit. Этот коммит имеет двух родителей: последний коммит текущей ветки и последний коммит ветки, которую мы вливаем.

# Переключаемся на основную ветку
git checkout main

# Вливаем ветку с функциональностью
git merge feature/user-auth

После выполнения этой команды история будет выглядеть так:

      A---B---C  feature/user-auth
     /         \
D---E---F---G---H  main (коммит слияния H)

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

Преимущества merge

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

Как работает git rebase

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

# Переключаемся на ветку с функциональностью
git checkout feature/user-auth

# Переносим коммиты поверх main
git rebase main

История после rebase:

               A'--B'--C'  feature/user-auth
              /
D---E---F---G  main

Коммиты A, B, C превратились в A', B', C' — это новые объекты с теми же изменениями, но другими родителями и хешами.

Преимущества rebase

Главный плюс — линейная история без лишних merge-коммитов. После ребейса кажется, что работа велась последовательно, что упрощает просмотр через git log и поиск ошибок через git bisect.

Интерактивный rebase

Интерактивный режим — мощный инструмент для редактирования истории перед публикацией изменений.

# Редактируем последние 3 коммита
git rebase -i HEAD~3

В открывшемся редакторе можно выбрать действие для каждого коммита:

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

# Объединяем черновые правки перед отправкой пул-реквеста
pick a1b2c3d Добавляем авторизацию через JWT
squash e4f5a6b Правим опечатку в комментарии
squash c7d8e9f Убираем отладочный console.log

Результат — один чистый коммит вместо трёх, что делает историю пул-реквеста читаемой.

Когда использовать merge

Слияние публичных веток. Если ветка уже запушена и другие разработчики работают на её основе, merge — единственный безопасный вариант. rebase изменит хеши коммитов и сломает историю у коллег.

Интеграция фич в main или develop. Merge-коммит служит явной отметкой о том, когда именно функциональность была влита. Это удобно при работе с релизами.

Сохранение контекста. Когда важно понять, что изменения пришли из конкретной feature-ветки, merge-коммит даёт этот контекст.

# Стандартное слияние feature в develop
git checkout develop

# Флаг --no-ff гарантирует создание merge-коммита даже при fast-forward
git merge --no-ff feature/payment-module

Когда использовать rebase

Обновление локальной ветки. Когда main обновился, пока вы работали над фичей, ребейс позволяет подтянуть изменения без лишнего merge-коммита.

# Обновляем main
git checkout main
git pull origin main

# Переносим нашу ветку поверх обновлённого main
git checkout feature/search
git rebase main

Чистка истории перед пул-реквестом. С помощью интерактивного ребейса можно объединить черновые коммиты в осмысленные единицы работы.

Локальные эксперименты. Пока ветка существует только у вас, её можно свободно переписывать.

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

Rebase публичных веток

Самая опасная ошибка — делать rebase ветки, которую уже видят другие разработчики. Это изменяет хеши всех коммитов, и при следующем git pull коллега получит конфликты или дублирующиеся коммиты.

# ОПАСНО: если origin/feature уже используют другие разработчики
git rebase main
git push --force origin feature/shared-branch

Правило простое: никогда не делайте rebase ветки, которая есть на удалённом сервере и которую используют другие.

Потеря коммитов при force push

После ребейса приходится делать git push --force. Без осторожности можно перезаписать чужие коммиты. Используйте более безопасный вариант:

# Не перезапишет, если кто-то успел запушить после вас
git push --force-with-lease origin feature/my-branch

Бездумный squash

Объединять коммиты перед мержем полезно, но не всегда. Если каждый коммит несёт смысловую нагрузку и может быть полезен для git blame или git bisect, оставьте их раздельными.

Заключение

Выбор между merge и rebase — это вопрос контекста. Для публичных веток и интеграции фич используйте merge: он безопасен и честен. Для поддержания чистоты локальной истории и подготовки пул-реквестов — rebase. Комбинируя оба подхода, вы получите историю репозитория, которая одновременно отражает реальную работу и остаётся удобной для чтения.

Главное правило: не переписывайте историю, которую уже видят другие.