Как работает Git rebase и чем он отличается от merge

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

Что делает git merge

Команда git merge объединяет две ветки, создавая новый коммит слияния (merge commit), который содержит историю обеих веток.

Пример:

git checkout main
git merge feature

Результат — история сохраняет оба пути развития.
В логах (git log --graph) вы увидите две линии, которые сходятся в одну:

*   Merge branch 'feature'
|\
| * Добавил новую функцию
* | Исправил баг
|/
* Начальный коммит

Плюсы merge:

• История полностью сохраняется.
• Безопасен — не меняет существующие коммиты.
• Подходит для публичных веток (например, main, develop).

Минусы:

• История становится «ветвистой» и со временем сложнее читается.

Что делает git rebase

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

Пример:

git checkout feature
git rebase main

Git берёт все коммиты из feature, которые отсутствуют в main, и применяет их заново поверх последнего коммита main.
История становится линейной:

* Добавил новую функцию
* Исправил баг
* Начальный коммит

Плюсы rebase:

• Чистая и линейная история.
• Удобно читать git log и git blame.
• Проще делать последующие слияния.

Минусы:

• Меняет историю коммитов — старые хэши заменяются новыми.
• Опасно использовать на общих ветках, которые уже кто-то забрал (pull).

Основное отличие merge и rebase

Или проще:

• merge соединяет истории,
• rebase делает вид, что история всегда была прямой.

Когда стоит использовать rebase

Обычно rebase применяют перед тем, как отправить свою ветку в общий репозиторий.
Например:

git checkout feature
git fetch origin
git rebase origin/main

Так ветка feature получит все новые изменения из main, а история останется аккуратной.
После успешного rebase можно спокойно сделать:

git checkout main
git merge feature

Теперь merge будет «fast-forward» — без лишнего merge-коммита.

Пример в действии

Допустим, у нас:

main:    A---B
feature:     \---C---D

После git rebase main структура станет:

main:    A---B---C'---D'

(Коммиты C и D будут пересозданы с новыми хэшами C' и D').

Если вместо этого сделать merge, получится:

main:    A---B---M
feature:     \---C---D

(M — новый merge-коммит.)

Что делать при конфликтах во время rebase

Если возникает конфликт, Git остановит процесс и попросит его вручную исправить.
После исправления нужно:

git add .
git rebase --continue

Если хотите отменить rebase и вернуть всё назад:

git rebase --abort

Когда не стоит использовать rebase

• Если ветка уже отправлена на общий репозиторий и её кто-то мог забрать — иначе придётся решать конфликты заново.
• Если важно сохранить историю разработки (например, для аудита).
• Если проект использует автоматическую проверку merge-коммитов (CI/CD, release notes и т.п.).

Заключение

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

Главное правило: не делайте rebase общих веток.
Для всего остального — это отличный способ держать проект чистым и читаемым.