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

Question

Accepted Answer

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

## Merge — сохраняет историю (объединяет)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — переписывает для линейной истории (воспроизводит)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **перемещает** коммиты вашей ветки, чтобы они начинались с вершины другой ветки, создавая новые коммиты — в результате получается чистая, линейная история.

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

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Когда использовать каждый подход

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Почему это важно

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

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

Понимание компромиссов (merge: точен, но потенциально загроможден коммитами слияния; rebase: чист и линеен, но переписывает коммиты) помогает выбрать подход в зависимости от того, цените ли вы истинную историю или линейную чистоту.

Максимально критично понимать **золотое правило rebase** — **никогда не делайте rebase коммитов, которые были отправлены/поделены** — это необходимо, потому что rebase переписывает коммиты (давая им новые хеши), поэтому применение rebase к поделенной истории расходится с тем, что есть у сотрудников, вызывая серьезные проблемы и конфликты; rebase безопасен только для локальных, неотправленных коммитов.

Это правило безопасности жизненно важно и часто является источником проблем при его нарушении.

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

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