Rebase: что это, чем отличается от Merge и принцип работы

Что такое Rebase?

Rebase (перебазирование) — это операция Git, которая переносит коммиты из текущей ветки на новую точку отсчёта (base). Вместо того чтобы создавать merge commit, rebase берёт каждый коммит из исходной ветки и по очереди применяет его поверх нового base. В результате получается линейная последовательность коммитов без ветвлений.

Название rebase происходит от "re-base" — изменить базу. Если merge объединяет две ветки в одной точке, то rebase фактически переносит вашу ветку целиком на новое место, делая вид, что вы начинали разработку от актуального состояния целевой ветки. Это создаёт иллюзию идеально последовательной работы.

По данным Atlassian, 2025, команды, использующие rebase для feature-веток, тратят на 30% меньше времени на анализ истории коммитов по сравнению с командами, использующими исключительно merge. Линейная история упрощает git blame, bisect и просмотр лога через git log --oneline.

Принципиальное отличие от Merge

Merge объединяет ветки, создавая коммит с двумя родителями. Rebase переписывает историю: новые коммиты создаются заново с новыми хешами, хотя изменения в них идентичны исходным. Это означает, что rebase меняет SHA-идентификаторы коммитов, что критично для публичных веток.

Как работает Rebase

Механизм rebase состоит из четырёх шагов: Git определяет общий предок (merge base) текущей и целевой ветки, затем последовательно применяет каждый коммит текущей ветки поверх целевой. Если на каком-то шаге возникает конфликт — rebase останавливается и ждёт разрешения.

# Стартовая ситуация: feature отстала от develop на 3 коммита
git checkout feature/new-login
git rebase develop

# Git берёт 3 коммита из feature и применяет их поверх develop
# Если конфликтов нет — rebase завершается автоматически
# Если есть — Git останавливается на конфликтном коммите

После rebase feature-ветка содержит все коммиты из develop плюс свои собственные коммиты, которые выглядят как продолжение develop. Это позволяет сделать merge в develop через fast-forward, без создания merge commit.

Пошаговый процесс

Рассмотрим детальный пример: разработчик создал feature-ветку от develop, сделал два коммита, а за это время в develop добавили три коммита другие разработчики. Rebase перенесёт два коммита feature на новое место, создав их копии с новыми SHA.

# 1. Создать feature-ветку
git checkout -b feature/payment-refactor develop

# 2. Сделать коммиты в feature
git commit -m "refactor: extract payment validation"
git commit -m "refactor: add payment gateway interface"

# 3. Обновить develop (работа коллег)
git checkout develop
git pull

# 4. Перебазировать feature поверх нового develop
git checkout feature/payment-refactor
git rebase develop

# 5. Теперь feature можно слить через fast-forward
git checkout develop
git merge feature/payment-refactor

Если на шаге 4 возникает конфликт, Git останавливается на проблемном коммите. Разработчик разрешает конфликт, делает git add и выполняет git rebase --continue. Если требуется пропустить коммит — git rebase --skip, если отменить весь rebase — git rebase --abort.

Автоматическое пропускание пустых коммитов

Флаг --empty управляет поведением rebase при пустых коммитах — ситуациях, когда все изменения коммита уже присутствуют в целевой ветке. По умолчанию rebase останавливается и запрашивает решение. С флагом --empty=drop Git автоматически пропускает такие коммиты без остановки, что ускоряет массовое перебазирование с большим количеством коммитов.

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

Interactive rebase (git rebase -i) — мощный инструмент для редактирования истории коммитов. Он открывает редактор со списком коммитов и key-командами: pick (оставить), reword (изменить сообщение), edit (изменить содержимое), squash (объединить с предыдущим), fixup (объединить без сообщения), drop (удалить).

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

# В редакторе откроется план rebase:
# pick a1b2c3 feat: add login screen
# pick d4e5f6 fix: login validation
# pick g7h8i9 fix: login layout
# pick j0k1l2 docs: add login comments

# Меняем на:
# pick a1b2c3 feat: add login screen
# squash d4e5f6 fix: login validation
# squash g7h8i9 fix: login layout
# drop j0k1l2 docs: add login comments

Результат: три коммита (login screen, validation, layout) сжаты в один, а коммит с комментариями удалён. Это позволяет подавать на код-ревью чистую историю без черновиков и исправлений. Interactive rebase — стандартный инструмент подготовки feature-ветки перед Pull Request.

Rebase vs Merge: сравнение

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

Практическое правило: используйте merge для интеграции в общие ветки (develop, main) и rebase для приведения личных feature-веток к актуальному состоянию. Многие команды комбинируют: rebase feature на develop, затем --no-ff merge в develop.

Влияние на git bisect

Git bisect — инструмент для поиска коммита, который внёс регрессию. При использовании merge git bisect корректно проходит через merge commit'ы, учитывая обоих родителей. При rebase bisect работает быстрее, так как история линейна и не требует ветвления. Однако если rebase был сделан после того, как коммиты стали известны команде, исходные SHA теряются, и bisect может не найти проблемный коммит.

Когда применять Rebase

Rebase оптимален в трёх сценариях: подготовка feature-ветки к Pull Request, обновление личной ветки до актуального состояния main/develop и чистка истории перед слиянием. В каждом случае rebase улучшает читаемость истории без риска для командной работы.

Перед Pull Request рекомендуется выполнить interactive rebase, чтобы объединить черновые коммиты (WIP, fix после ревью) в осмысленные логические единицы. Это облегчает код-ревью: ревьюер видит не 15 мелких коммитов, а 3-5 структурированных изменений с понятными сообщениями.

Для обновления feature-ветки rebase предпочтительнее merge, потому что он не создаёт лишних merge commit'ов. Если периодически делать git rebase develop внутри feature-ветки, после финального слияния не будет каскада из 10 merge commit'ов — только чистые коммиты фичи поверх develop.

Чистка истории через interactive rebase перед merge позволяет скрыть незначительные исправления (опечатки, форматирование) и сгруппировать коммиты по функциональности. Git-сообщения должны следовать соглашению Conventional Commits (fix:, feat:, refactor:, docs:), что генерирует автоматический changelog.

Риски и правила Rebase

Rebase — опасная операция, если применять её неправильно. Главный риск — переписывание опубликованной истории. Если разработчик сделал rebase ветки, которую другие уже запушили и используют, их локальные копии рассинхронизируются, и им придётся выполнять force-pull с риском потери данных.

• Golden Rule: никогда не делайте rebase коммитов, которые уже существуют в общем репозитории. Это касается любых веток, к которым есть доступ у других участников команды
• Force push: после rebase локальной feature-ветки требуется push с флагом --force-with-lease, который безопаснее --force, так как проверяет, не обновил ли кто-то ветку на сервере
• Потеря контекста: rebase уничтожает информацию о том, когда и от какой ветки создавалась feature-ветка. Если важно сохранить даты создания ветки — используйте merge
• Конфликты: при rebase конфликты нужно разрешать для каждого коммита по отдельности, что может быть утомительно при большом количестве коммитов

Для минимизации рисков соблюдайте правило: rebase только для личных веток, которые не были опубликованы. Если ветка уже в общем репозитории — используйте merge с --no-ff. При необходимости rebase опубликованной ветки — предупредите команду и согласуйте force push заранее.

Автоматическая защита от опасного rebase реализуется через server-side hooks: pre-receive hook на стороне Git-сервера может проверять, не переписывает ли push опубликованные коммиты. GitHub и GitLab предоставляют встроенную защиту для protected branch — force push блокируется, если не снята защита администратором.