Как на самом деле работают merge и rebase

Обе команды начинают с поиска merge base — ближайшего общего предка. Когда feature и main разошлись, они всё ещё разделяют историю до какого-то коммита. Merge base — это самый недавний коммит, достижимый из обеих вершин:

git merge-base main feature      # -> SHA, где две ветки в последний раз совпадали

Это точка отсчёта, относительно которой меряется всё остальное: она говорит git, какие изменения уникально твои, а какие уникально их с момента расхождения. Ошибись с базой — и не отличишь реальную правку от «это всегда тут было».

Merge делает трёхстороннее слияние: base против ours против theirs. Двусторонний дифф двух вершин не скажет, кто изменил строку, — только что они различаются. Поэтому git сравнивает три снимка: merge base, ours (текущая ветка) и theirs (вливаемая ветка). Для каждого участка файла:

• изменён только на одной стороне → берём эту сторону автоматически;
• изменён на обеих сторонах одинаково → берём;
• изменён на обеих сторонах по-разному → конфликт, ты его разрешаешь.

База — это то, что делает «изменена только одна сторона» разрешимым; без неё каждое различие выглядело бы конфликтом.

Merge пишет ОДИН коммит с ДВУМЯ родителями, сохраняя форму ветвления. Результат успешного слияния — новый merge-коммит, чей первый родитель — старая вершина main, а второй — вершина feature:

git switch main
git merge feature                # -> создаёт merge-коммит, родители: [main, feature]

История теперь явно ветвится и сходится обратно. Ничего не переписано: обе исходные ветки существуют дословно, и граф фиксирует, что слияние произошло, когда и что сошлось вместе. Это настоящая история — включая грязную реальность того, что две линии работы шли параллельно.

Rebase переигрывает твои коммиты один за другим на новой базе как совершенно новые коммиты. Вместо соединения веток rebase перемещает твою. git switch feature; git rebase main концептуально делает:

1. Вычисляет патч каждого коммита feature с момента merge base.
2. Сбрасывает feature на вершину main.
3. Заново применяет эти патчи по порядку, создавая новый коммит на каждый — новый родитель, новая метка времени, значит, новый SHA.

Старые коммиты брошены (достижимы только через reflog). Результат — прямая линия: история main, затем твои коммиты сверху, как будто ты всё время начинал с текущего main.

git switch feature
git rebase main                  # переигрывает коммиты feature на вершину main

Компромисс: настоящая история против чистой линейной — и золотое правило. Merge хранит точную, ветвящуюся запись ценой более загруженного графа. Rebase даёт опрятную, удобную для bisect прямую линию ценой переписывания коммитов в новые SHA. Это переписывание безопасно на коммитах, которые есть только у тебя, — и опасно на разделяемых:

Золотое правило rebase: никогда не делай rebase коммитов, существующих за пределами твоего локального репозитория (на которых другие могли основать работу).

Переписывание публичных коммитов даёт всем остальным расходящуюся историю и вынуждает к запутанным force-push и повторным слияниям. Делай rebase своей приватной фиче-ветки до того, как поделишься; merge — когда она уже публична.