Git rebase переносит серию коммитов текущей ветки на другой базовый коммит. Технически Git откладывает коммиты, которые отличаются от целевой ветки, переключается на неё, а затем поочерёдно применяет отложенные изменения поверх новой базы.
На концептуальном уровне rebase и merge решают разные задачи. Rebase переписывает историю, выстраивая её в линейную цепочку. Merge объединяет истории, сохраняя обе ветки видимыми.
Rebase уместен для локальных feature-веток, которые ещё не опубликованы и на которые не опираются другие участники. Для общих и публичных веток rebase не подходит — почему именно, разберём в разделе про «золотое правило».
Процесс состоит из трёх шагов:
Каждый перенесённый коммит получает новый SHA-хеш. История не дополняется — она физически переписывается: старые коммиты с исходными хешами перестают быть частью ветки.
Отдельная особенность — разрешение конфликтов. Коммиты применяются последовательно, поэтому конфликт может возникать на каждом переносимом коммите отдельно. При merge конфликты обрабатываются иначе.
Git merge объединяет две ветки, создавая новый merge-коммит с двумя (или более) родителями. Такой коммит фиксирует момент слияния и сохраняет ссылки на обе исходные линии разработки.
Частный случай — fast-forward merge. Если целевая ветка не расходилась с базой, отдельный merge-коммит не создаётся: указатель ветки просто передвигается вперёд.
При обычном (не fast-forward) merge история сохраняется как есть, включая параллельные ветки: видно, где разработка расходилась и где сходилась обратно.
| Критерий | Rebase | Merge |
| Форма истории | Линейная, без явных точек ветвления | Ветвящаяся, с merge-коммитами |
| Хеши коммитов | Меняются — риск для опубликованных веток | Не затрагиваются, добавляется только новый коммит |
| Разрешение конфликтов | На каждом переносимом коммите отдельно | Один раз для всего набора расходящихся изменений |
Интерактивный режим git rebase -i открывает редактор со списком коммитов и набором команд: squash, fixup, reword, edit, drop. Это позволяет перед применением менять порядок коммитов, объединять их, редактировать сообщения и содержимое, а также удалять лишние.
Типичный сценарий — привести в порядок локальные коммиты перед pull request: убрать промежуточные «fix typo», объединить логически связанные изменения в один коммит и сделать историю feature-ветки читаемой для ревьюера.
Основное ограничение сформулировано в Pro Git: не переписывать (rebase) коммиты, которые уже вытолкнуты в общий репозиторий и на которые могут опираться другие участники.
Последствия нарушения: после переписывания истории старые и новые версии коммитов существуют параллельно. Коллеги, продолжившие работу от старых коммитов, получат расхождение истории, дублирование коммитов и конфликты при синхронизации.
Rebase даёт чистую линейную историю без лишних merge-коммитов. Лог читается проще.
Merge не переписывает чужую историю и не создаёт риска дублирования коммитов.
Распространённая практика: rebase локально, пока ветка не опубликована, а при интеграции в основную ветку — merge или fast-forward.
Наши специалисты свяжутся с вами в ближайшее время и ответят на все вопросы.
Будем держать в курсе новостей и облачных трендов
