Ответ 1
Пример не очень хорош, потому что он учитывает только одно коммит (слияние или переустановка), создавая впечатление, что полученные коммиты похожи. В общем случае rebase добавит несколько коммитов, в то время как слияние добавит не более одного (ускоренные слияния не добавят ни одного).
Кроме того, до тех пор, пока конфликт не будет разрешен, или если вы разрешаете конфликты одинаково каждый раз, конечный контент C3 'и C5 будет таким же, но они остаются различными коммитами (поскольку C3' и C5 имеют разных родителей, у них также будут разные хэши, что более очевидно на иллюстрациях ниже). Соответственно, записанная история для каждого отличается. Примечание для rebase, история является линейной, а для слияния это lattice.
Рассмотрим тот же вопрос, когда слияние/перезагрузка совершает несколько коммитов, как показано на рисунке A Visual Git Reference "от Марка Лодато. Вы увидите, что конечный результат совсем другой.
git checkout master
git merge other # update master with tip of branch 'other' changes
Вы принимаете только:
- текущий фиксатор (ed489 ниже, поскольку вы находитесь на главном сервере),
- последняя фиксация другой ветки (которая представляет собой моментальный снимок, представляющий полное содержимое репо при разветвлении в
other, а не дельта) - их общий предок (b325c) и выполняет трехстороннее слияние.
В значении рабочего каталога и этапа на этой диаграмме обратите внимание на стрелки, идущие на трехстороннее слияние, а затем на рабочий каталог и этап. Рабочий каталог представляет все файлы, которые вы видите (на вашем жестком диске), некоторые из которых изменены в результате трехстороннего слияния. На сцене хранятся файлы, измененные с помощью трехстороннего слияния, которые затем используются для создания нового фиксации (f8bc5).
Это сильно отличается от rebase, который стремится к повторно применять каждое фиксацию ветки поверх ветки назначения:
git checkout topic # this time we are on topic
git rebase master # means: recreate every topic commits on top of master
at the end, we are still on (new) 'topic' branch
Вышеприведенная команда принимает все коммиты, которые существуют в '
topic', но не вmaster(а именно169a6и2c33a), повторяет их наmasterи затем перемещает ветвь ветки на новый наконечник. Обратите внимание, что старые коммиты будут [в конечном итоге] собирать мусор, если они больше не ссылаются.
Rebasing использует рабочий каталог и промежуточную область при повторном коммите (применяет изменения в рабочем каталоге, добавляет изменения в промежуточную область, фиксирует поэтапные изменения, повторяет). Как только все это будет сделано, голова переустановленной ветки будет установлена на последний из новых коммитов (f7e63).
2 дополнительных отличия:
- Объединить и переустановить различные рабочие процессы: См. "git merge vs. rebase"
- "ours" и "theirs" различаются между слиянием и rebase: "Почему значение "наши" и "их" отменено?"