В чем разница между git rebase и git merge

Вопрос

В чем разница между git rebase и git merge

Профессия

Frontend Developer

Что хочет услышать интервьюер

Интервьюер хочет убедиться, что кандидат понимает разницу между rebase и merge, их применение и последствия для истории коммитов. Также важно, чтобы кандидат мог объяснить, когда и зачем использовать каждый из этих методов.

Ключевые тезисы

• git merge объединяет две ветки, создавая новый merge-коммит, который сохраняет историю обеих веток.
• git rebase перемещает коммиты одной ветки в конец другой, переписывая историю и создавая линейную последовательность коммитов.
• merge предпочтителен для публичных веток, так как сохраняет историю изменений, а rebase — для локальных, чтобы упростить историю.
• rebase может вызвать конфликты, которые нужно разрешать поэтапно для каждого коммита, тогда как merge обычно требует одного разрешения конфликта.

Подробный ответ

Git merge и git rebase — два способа интеграции изменений из одной ветки в другую, дающие одинаковый результат, но с разной историей коммитов.

Git Merge

git merge объединяет две ветки, создавая merge-коммит — специальный коммит с двумя родителями.

A---B---C  (feature)
     /         \
D---E---F---G---M  (main)

Плюсы merge

• Сохраняет полную историю — видно, когда и что было смержено
• Безопасен — не изменяет существующие коммиты
• Хорош для командной работы

Минусы merge

• Создаёт дополнительные merge-коммиты
• История может стать запутанной при частых мержах

Git Rebase

git rebase «перебазирует» коммиты ветки — переносит их на вершину целевой ветки, создавая новые коммиты.

A'--B'--C'  (feature)
             /
D---E---F---G  (main)

Плюсы rebase

• Линейная, чистая история без лишних merge-коммитов
• Легче делать git bisect и git log

Минусы rebase

• Переписывает историю — создаёт новые хэши коммитов
• Опасен для публичных веток — может испортить историю у коллег

Золотое правило

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

Практические примеры

Пример 1

Merge: слияние feature в main

git checkout main
git merge feature
# Создаётся merge-коммит (если fast-forward невозможен)

В логе будет виден merge-коммит с двумя родителями и полная история обеих веток.

Пример 2

Rebase: перебазирование перед merge

# Обновляем feature-ветку относительно main
git checkout feature
git rebase main

# Теперь можно сделать fast-forward merge
git checkout main
git merge feature

Результат — линейная история без merge-коммитов.

Пример 3

Interactive rebase: очистка коммитов

git rebase -i HEAD~3

Откроется редактор со списком последних 3 коммитов:

pick abc1234 feat: add button
pick def5678 fix: button color
pick ghi9012 fix: typo in button

Можно изменить pick на squash или fixup, чтобы объединить несколько коммитов в один чистый коммит.

Частые ошибки

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

Связанные темы

• Связанная тема которую стоит изучить: Работа с ветками в Git, включая создание, переключение и удаление веток.
• Еще одна связанная тема: Разрешение конфликтов в Git, включая использование команд git status, git diff, и git mergetool.

Follow-up вопросы

Когда лучше использовать rebase, а когда merge?

Уровень: basic

Rebase лучше использовать для локальных веток, чтобы упростить историю перед пул-реквестом. Merge предпочтителен для публичных веток (например, main или develop), чтобы сохранить историю изменений и избежать перезаписи коммитов.

Какие риски связаны с использованием rebase?

Уровень: intermediate

Rebase переписывает историю коммитов, что может вызвать проблемы, если ветка уже опубликована. Также rebase требует разрешения конфликтов для каждого коммита, что может быть трудоемким.

Как rebase влияет на историю коммитов в сравнении с merge?

Уровень: basic

Rebase создает линейную историю, перемещая коммиты одной ветки в конец другой. Merge сохраняет историю обеих веток, создавая новый merge-коммит с двумя родителями.

Можно ли использовать rebase после merge? Если да, то зачем?

Уровень: advanced

Да, это можно сделать для упрощения истории перед интеграцией изменений. Например, после merge feature-ветки в develop можно выполнить rebase, чтобы убрать лишние merge-коммиты и сделать историю чище.

Как разрешать конфликты при rebase?

Уровень: intermediate

При rebase конфликты возникают для каждого коммита, который их вызывает. Нужно последовательно исправлять конфликты, использовать git add для помеченных файлов и продолжать rebase командой git rebase --continue.