merge объединяет ветки, честно сохраняя всё как было. rebase решает ту же задачу иначе: переносит ваши коммиты на новое основание, переписывая их. Результат — прямая, читаемая история без ромбов и merge-коммитов. Цена — правила безопасности, которые нужно знать твёрдо. Разберём без религиозных войн «merge vs rebase».
Что делает rebase
Вы работали в ветке, main ушёл вперёд. Вместо вливания main в себя (merge-коммит в вашей ветке) — переставим вашу ветку на свежий main:
git switch feature-export
git rebase main
Git по одному «переприменяет» ваши коммиты поверх верхушки main. Внешне изменения те же, но история выглядит так, будто вы начали работу от свежего main. Важно понимать: это новые коммиты — с новыми идентификаторами; старые заменены. Конфликты возможны, как при merge, — решаются так же, продолжение git rebase --continue, отмена --abort.
Тот же механизм в ежедневном git pull --rebase: ваши локальные коммиты переносятся поверх свежих серверных — без мусорных merge-коммитов «Merge branch main into main».
Интерактивный rebase: приборка перед ревью
Реальная работа порождает черновую историю: «wip», «поправил опечатку», «ещё раз fix». Перед pull request её можно превратить в аккуратную:
git rebase -i main
Откроется список ваших коммитов с командами:
pick a1b2c3 feat: экспорт заказов в CSV
squash d4e5f6 wip
fixup g7h8i9 поправил опечатку
reword j0k1l2 добавил тесты экспорта
pick— оставить как есть;reword— поправить сообщение;squash— приклеить к предыдущему (сообщения объединятся);fixup— приклеить, выбросив сообщение;- строки можно переставлять и удалять (
drop).
Итог: три черновых коммита стали одним осмысленным. Если команда сливает через squash — усердствовать не надо; если через rebase/merge — приборка делает вашу историю подарком для будущих читателей.
Золотое правило
Не переписывайте историю, которую уже отправили в общую ветку. Rebase создаёт новые коммиты — у коллег, успевших забрать старые, история разойдётся с вашей, и распутывание будет мучительным.
Практическая формула безопасности: переписывать можно свою ветку до слияния (даже уже запушенную — тогда git push --force-with-lease, это ваша личная ветка); нельзя — main, develop и любые ветки, от которых работают другие. Отсюда и ответ на «merge или rebase»: в личной ветке — rebase на здоровье; общие ветки объединяются merge.
cherry-pick: перенести один коммит
Иногда нужна не ветка целиком, а один коммит из неё — классика: багфикс из main нужно доставить в ветку релиза 2.3.
git switch release-2.3
git cherry-pick a1b2c3
Git применяет изменения указанного коммита к текущей ветке (как отдельный новый коммит). Здесь атомарность коммитов из статьи про историю окупается буквально: атомарный багфикс переносится одной командой, а «фикс внутри коммита-свалки» — только руками.
Коротко
- Rebase переносит ваши коммиты на новое основание: история прямая, но коммиты — новые. Конфликты решаются как в merge (
--continue/--abort). pull --rebase— чистая ежедневная синхронизация без мусорных merge-коммитов.rebase -i— приборка ветки перед ревью: squash/fixup/reword/drop.- Золотое правило: не переписывать отправленное в общие ветки. Своя ветка — можно (
--force-with-lease); main — никогда. - cherry-pick переносит отдельный коммит — атомарные коммиты делают это возможным.
Что почитать дальше
- Отмена и спасение — reset, revert, reflog: страховочная сетка, если rebase пошёл не туда.
- Pull request и код-ревью — где приборка истории встречается с процессом команды.
- Модели ветвления — финал цикла: как всё это собирается в процесс.