Что такое git rebase

Короткий ответ: git rebase меняет базу для ваших коммитов. Если вы работали в ветке feature/login, а main ушел вперед, rebase позволяет взять ваши коммиты и применить их поверх нового состояния main.

Не ограничивайтесь фразой "переносит коммиты". Точнее так: Git создает новые коммиты с теми же изменениями, но уже на другой базе. Поэтому меняются хэши, а значит меняется история ветки.

Типичный сценарий:

git switch main
git pull
git switch feature/login
git rebase main

После этого история feature-ветки выглядит так, будто вы начали работу от свежего main. Это удобно для читаемого PR и для проектов, где команда предпочитает линейную историю.

Представьте, что ваша ветка ответвилась от старого коммита main. Потом в main появились новые изменения. Rebase не добавляет merge-коммит. Он заново применяет ваши изменения поверх нового конца main.

До rebase:

A - B - C  main
     \
      D - E  feature

После git rebase main:

A - B - C  main
         \
          D' - E'  feature

Коммиты D' и E' похожи на старые D и E по изменениям, но это уже новые объекты Git. Поэтому нельзя говорить, что rebase ничего не меняет в истории.

На интервью лучше не спорить, что всегда лучше. Покажите критерий выбора. Rebase удобен, когда вы работаете со своей веткой и хотите получить чистую последовательность коммитов. Merge безопаснее, когда нужно объединить уже опубликованные ветки и сохранить факт объединения.

Для frontend-разработчика это практичный вопрос. Если вы перепишете историю общей ветки с компонентами дизайн-системы, коллеги могут получить расхождение локальных веток, дубли коммитов и сложные конфликты. Если вы аккуратно сделаете rebase своей feature-ветки перед PR, ревьюеру будет проще читать изменения.

Rebase сам по себе не меняет работу браузера или React. Риск появляется после конфликтов и новой базы. Вы могли получить свежий код дизайн-системы, новый API-клиент, другой lockfile или изменения в роутинге. Git применит патч, но не проверит, что форма показывает правильный loading, ошибка не потерялась, а общий компонент не сломал доступность.

Поэтому после rebase проверяйте не только статус Git. Посмотрите diff, запустите доступные проверки и пройдите руками затронутый сценарий, если конфликт был в UI, сетевом слое, типах, зависимостях или общем компоненте.

git rebase -i открывает список коммитов и позволяет отредактировать локальную историю. Обычно его используют перед pull request, чтобы убрать шум. Например, объединить несколько мелких коммитов, поправить сообщение, удалить случайный коммит с временным логом.

Пример:

git rebase -i HEAD~3

В редакторе можно оставить pick, заменить на reword для изменения сообщения, использовать squash для объединения коммитов. Это полезно, если в истории есть коммиты вроде fix typo, wip и try again.

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

Во время rebase Git применяет ваши коммиты по одному. Поэтому один и тот же файл может конфликтовать несколько раз, если несколько ваших коммитов меняли одну область. Это нормально, но требует внимания.

Базовая последовательность при конфликте:

# исправьте конфликтные файлы руками
git add src/components/LoginForm.tsx
git rebase --continue

Если вы поняли, что начали rebase не на ту ветку или конфликт стал слишком рискованным, можно отменить процесс:

git rebase --abort

После успешного rebase не ограничивайтесь тем, что Git завершил команду. Запустите проверки, которые реально ловят ошибки в вашем проекте: тесты, линтер, typecheck или сборку. Если конфликт был в UI или сетевом слое, дополнительно проверьте loading, error и empty state для затронутого сценария.

Можно ответить так:

Git rebase переприменяет коммиты текущей ветки поверх другой базы, например поверх свежего main. Это делает историю линейной и часто удобно перед pull request. Но rebase переписывает историю, потому что у коммитов меняются хэши. Поэтому я использую его в своих локальных feature-ветках и не делаю молча на общих ветках.

Если хотите усилить ответ, добавьте практику:

При конфликте я исправляю файлы, делаю git add и продолжаю через git rebase --continue. Если ветку после rebase нужно обновить на remote, для личной ветки использую git push --force-with-lease. После конфликтов запускаю проверки проекта.

Такой ответ показывает три вещи: вы понимаете механику Git, умеете выбирать безопасный workflow и думаете о последствиях для команды.