Почему при локальных слияниях используется rebase?

Почему при локальных слияниях используется rebase?

Основная идея

Git rebase — это операция переписывания истории коммитов, которая создаёт линейную последовательность вместо ветвлений. При локальных слияниях (когда вы объединяете свою ветку с основной веткой на локальной машине) rebase часто предпочтительнее merge по нескольким причинам.

Чистая история коммитов

Когда вы используете git rebase:

Было:
A --- B --- C (main)
       \\
        D --- E (feature)

Стало:
A --- B --- C --- D' --- E' (main)

История остаётся линейной и читаемой, без диагональных стрелок в графе. Это особенно важно при просмотре истории: git log --graph выглядит аккуратно.

Избежание merge-коммитов

Merge создаёт дополнительный коммит слияния:

A --- B --- C ------- F (merge commit)
       \\
        D --- E -----

Это загрязняет историю и усложняет анализ. При наличии нескольких локальных веток возникает паутина merge-коммитов.

Упрощение code review

Когда вы отправляете pull request после rebase, рецензент видит:

• Только ваши изменения в чистом виде
• Логическую последовательность коммитов
• Не отвлекается на merge-коммиты

При merge проще случайно включить чужие изменения в историю.

Когда merge лучше?

Используй merge если:

• Ветка уже опубликована (public branch)
• Слияние стратегическое (объединение двух полноценных веток)
• Нужна запись о том, что произошло слияние

Типичный workflow

git checkout feature-branch
git rebase main          # Переписываем нашу ветку на top of main
# Если конфликты — решаем и git rebase --continue
git checkout main
git merge --ff-only feature-branch  # Fast-forward merge

Ключевое правило: rebase для локального кода, merge для опубликованных веток. Это предотвращает путаницу в истории и облегчает коллаборацию в команде.