> Что происходит с коммитами ветки feature при выполнении rebase на ветку develop (Go)

Короткий ответ

При git rebase feature develop коммиты ветки feature не удаляются и не теряются - они пересоздаются поверх актуального состояния develop. Каждый коммит feature получает новые SHA-1 хеши, так как меняются родительские связи и, возможно, содержимое при разрешении конфликтов. Старые коммиты остаются в reflog до сборки мусора. Ветка feature перемещается на новую цепочку коммитов, а develop остаётся без изменений.

Подробное объяснение

Rebase - это операция, которая переписывает историю ветки. Механизм работы:

1. Git находит общий предок (merge base) между feature и develop.
2. Вычисляет набор коммитов, уникальных для feature (от merge base до tip feature).
3. Перемещает указатель feature на tip develop.
4. Последовательно применяет каждый коммит из набора поверх нового base.

Каждый коммит применяется заново через механизм cherry-pick: создаётся новый коммит с тем же автором, сообщением и изменениями, но с новым родителем и временем. Если изменения конфликтуют с текущим состоянием develop, git приостанавливает rebase и просит разрешить конфликт.

Важные следствия:

• SHA-1 хеши всех перемещённых коммитов изменяются, даже если содержимое идентично.
• Оригинальные коммиты остаются доступны через git reflog примерно 30 дней (настраивается через gc.reflogExpire).
• Если rebase прерван на середине, ветка feature находится в состоянии detached HEAD - нужно либо продолжить (git rebase --continue), либо отменить (git rebase --abort).
• Rebase не трогает develop - только feature перемещается.

На практике

Для senior-разработчика важно понимать не только механику, но и последствия для командной работы:

• Rebase переписывает историю - если feature уже запушена в общий remote, другие разработчики получат конфликты при pull. Нужно использовать git pull --rebase или force-push с осторожностью.
• После rebase на develop история становится линейной - это удобно для code review и git bisect.
• Если feature долго живёт и develop сильно ушёл вперёд, rebase может потребовать разрешения множества конфликтов. Альтернатива - merge, который сохраняет историю, но создаёт merge commit.
• Для long-running веток (например, release) merge предпочтительнее, для коротких feature-веток - rebase.
• Перед rebase стоит сделать бэкап ветки: git branch feature-backup.

Пример кода

BASH
# Переключиться на feature и выполнить rebase на develop
git checkout feature
git rebase develop

# Если конфликты - разрешить, затем:
git add <resolved-files>
git rebase --continue

# Отмена rebase при проблемах
git rebase --abort

# Просмотр оригинальных коммитов после rebase
git reflog

# Force push после rebase, если ветка уже была запушена
git push --force-with-lease origin feature

Как отвечать на собеседовании

Начни с краткого определения: rebase пересоздаёт коммиты поверх другого base. Затем опиши последовательность шагов: поиск merge base, вычисление уникальных коммитов, применение поверх нового base. Обязательно упомяни, что хеши меняются, а старые коммиты остаются в reflog.

Покажи понимание практических последствий: линейная история, конфликты, force-push. Если спросят про отличие от merge - подчеркни, что merge сохраняет историю и создаёт merge commit, а rebase переписывает её.

Для senior-уровня добавь рассуждение о trade-off: rebase даёт чистую историю, но опасен для общих веток. Упомяни --force-with-lease как безопасную альтернативу force-push.

Что проверяет интервьюер

• Понимание внутреннего механизма git: merge base, cherry-pick, пересоздание коммитов.
• Осознание, что хеши меняются и оригинальные коммиты не теряются мгновенно.
• Умение оценивать риски: переписывание публичной истории, конфликты.
• Практические навыки: команды для разрешения конфликтов, отмены rebase, force-push.
• Способность объяснить, когда rebase уместен, а когда лучше merge.

Типичные ошибки

• Утверждение, что rebase удаляет коммиты - они остаются в reflog.
• Забывают, что хеши меняются даже без изменений содержимого.
• Путают порядок: git rebase develop из ветки feature, а не наоборот.
• Не упоминают про detached HEAD при конфликте.
• Рекомендуют force-push без --force-with-lease - это опасно для командной работы.
• Говорят, что rebase "переносит" коммиты - на самом деле они пересоздаются.