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

Что проверяют

Понимаете ли вы, что одна операция сохраняет историю, а вторая переписывает, и знаете ли главное правило про общие ветки.

Как отвечать

merge создаёт коммит слияния с двумя родителями. История сохраняется как есть: видно, что ветка существовала и когда влилась. Граф получается ветвистым.

rebase переносит коммиты ветки поверх новой основы, создавая их копии с новыми идентификаторами. История становится линейной, коммита слияния нет, но исходные коммиты заменены другими.

Отсюда главное правило: не переписывать историю, которая уже опубликована. Ребейз ветки, с которой работает кто-то ещё, заставит его разбираться с расходящимися историями. Своя ветка до пул-реквеста это нормально, общая ветка нет.

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

Полезные детали: конфликты при ребейзе решаются по одному коммиту, поэтому их бывает больше, чем при слиянии; git rebase -i позволяет объединить и переписать коммиты; git pull --rebase избавляет от бессмысленных коммитов слияния при обновлении своей ветки; git reflog спасает, если ребейз пошёл не так.

Где спотыкаются

Делают ребейз общей ветки и ломают работу коллегам.

Пушат после ребейза с --force вместо --force-with-lease и затирают чужие коммиты.

Считают, что ребейз «удаляет» коммиты: он создаёт их копии, старые ещё есть в reflog.

Не могут объяснить, откуда берётся коммит слияния и почему у него два родителя.