Один вопрос про Git, на котором горят даже тимлиды

«Объясни, что именно делает git rebase и почему он переписывает историю». Этот вопрос звучит на каждом втором бэкенд-собесе — и на нём регулярно буксуют люди с пятью годами опыта. Потому что между «я пользуюсь rebase» и «я понимаю, как он работает» — пропасть.

Почему интервьюеры задают именно этот вопрос

Rebase — лакмусовая бумажка. Он разделяет тех, кто выучил команды, и тех, кто понимает, как Git устроен внутри. Если разработчик может объяснить механику rebase — он понимает объектную модель Git, знает про SHA-хеши, умеет работать с историей. Если нет — он пользователь инструмента, а не инженер.

Один вопрос — и интервьюер видит глубину.

Плохой ответ

«Rebase перемещает коммиты из одной ветки на другую. В отличие от merge, он не создаёт merge-коммит и делает историю линейной.»

Формально верно. Но это описание результата, не процесса. Это как сказать «самолёт летает, потому что у него крылья». Ты описал что, но не как и почему.

Красные флаги:

• «Перемещает коммиты» — нет, не перемещает. Он создаёт новые. Старые остаются в reflog. Слово «перемещает» выдаёт непонимание внутренней механики.
• Нет упоминания SHA-хешей. Если ты не знаешь, что после rebase хеши коммитов меняются — ты не понимаешь, почему rebase переписывает историю.
• Нет контекста, когда rebase опасен. Назвать плюсы без ограничений — признак поверхностного знания.

Хороший ответ

«Когда ты делаешь git rebase main, Git выполняет несколько шагов. Сначала находит общего предка текущей ветки и main — merge base. Затем берёт все коммиты в текущей ветке, которых нет в main, и сохраняет их как набор патчей — diff'ов. После этого сбрасывает текущую ветку на HEAD main. И поочерёдно применяет каждый патч как новый коммит.

Ключевой момент: это именно новые коммиты. У них новые SHA-хеши, потому что хеш в Git вычисляется из содержимого, родительского коммита, автора и timestamp. Родитель изменился — хеш изменился. Поэтому rebase "переписывает историю" — старые коммиты остаются в объектной базе как orphaned, но ветка теперь указывает на новые.

Под капотом rebase — это серия cherry-pick'ов. git rebase main для коммитов A, B, C по сути делает: checkout main, cherry-pick A → A', cherry-pick B → B', cherry-pick C → C'. Отсюда и конфликты на каждом шаге — потому что каждый патч применяется отдельно.

Именно поэтому rebase опасен на публичных ветках. Если я сделал rebase и force push, а коллега уже стянул старые коммиты — у него в истории A, B, C, а на remote теперь A', B', C'. Git считает это разными коммитами. При pull коллега получит дубли или конфликты.»

Почему это ответ уровня тимлида:

• Описывает механику, а не результат. Merge base → патчи → сброс → применение. Это не пересказ документации, это понимание.
• Объясняет через SHA-хеши — почему новые коммиты, а не перемещённые.
• Связывает rebase с cherry-pick. Показывает, что видит инструменты не изолированно, а как систему.
• Называет конкретный опасный сценарий — force push после rebase при совместной работе.

Что покажет ещё более глубокое знание

Если интервьюер копнёт дальше, вот что отличает эксперта:

«Как восстановить коммиты после неудачного rebase?»

git reflog
## Находим SHA коммита до rebase
git reset --hard HEAD@{5}

Reflog — лог всех перемещений HEAD в локальном репозитории. Каждый checkout, commit, reset, rebase записывается. Коммиты не удаляются при rebase — они становятся orphaned и живут в reflog 90 дней. Знание reflog — это разница между «всё пропало» и «починил за минуту».

«Чем git rebase --onto отличается от обычного rebase?»

git rebase --onto main feature-a feature-b

--onto позволяет перебазировать ветку на произвольный коммит, а не только на ту ветку, от которой ты ответвился. Это нужно, когда feature-b зависит от feature-a, а feature-a уже влита в main. Ты хочешь перебазировать feature-b на main, минуя feature-a. Большинство разработчиков никогда не использовали --onto и не могут объяснить, зачем он нужен.

Что на самом деле проверяет этот вопрос

Не знание Git. Git — это инструмент. Вопрос проверяет, как ты мыслишь:

• Можешь ли ты объяснить сложное просто? Описать rebase через cherry-pick — это навык декомпозиции.
• Понимаешь ли ты инструменты, которые используешь? Или просто повторяешь заученные команды?
• Знаешь ли ты ограничения? Тимлид, который не понимает, когда rebase опасен, — это бомба замедленного действия в команде.

Мы разбирали похожий паттерн в посте про REST API — один вопрос, и по глубине ответа видно всё. С Git работает тот же принцип: не что ты знаешь, а насколько глубоко.

Если хочешь проверить, на каком уровне твои ответы по Git и другим темам — Sobes AI разберёт каждый ответ, покажет, где ты на уровне «выучил команды», а где уже «понимаю механику». Лучше узнать это в тренировке, а не на собесе.