Merge или rebase: что выбрать
Вопрос
Объясни разницу между merge и rebase. Что ты используешь в работе и почему?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
merge создаёт merge-коммит и не переписывает историю
rebase переносит коммиты на новую базу, хеши меняются, история линейная
rebase нельзя делать с общими запушенными коммитами
после rebase своей ветки нужен push --force-with-lease
конфликты при rebase решаются по коммитам: add и rebase --continue
выбор зависит от договорённостей команды: squash merge, linear history и т.п.
Что могут спросить следом
- Что будет, если сделать rebase ветки, на которой работает коллега?
- Чем squash merge в GitHub отличается от rebase merge?
- Как отменить неудачный rebase?
Разбор
Обе команды интегрируют изменения одной ветки в другую. merge делает это без переписывания: если ветки разошлись, появляется merge-коммит с двумя родителями, и видно, когда что вливали. rebase берёт мои коммиты и применяет их заново поверх целевой ветки, получаются новые коммиты с новыми хешами и линейная история без лишних узлов.
В работе я обычно ребейзю свою фичевую ветку на свежий main перед ревью, чтобы конфликты решать у себя и чтобы история читалась, и пушу через --force-with-lease. Общие ветки не ребейзю никогда: коллеги получат расходящуюся историю. Конфликты при rebase решаются по каждому коммиту: правлю файл, git add, git rebase --continue; если всё пошло не так, git rebase --abort или reflog. Итоговый способ вливания в main зависит от команды: кто-то предпочитает squash merge, кто-то merge-коммиты ради истории.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.