О слиянии и перебазировании Git

Question

Выше приведен результат слияния и перебазирования.

Мой вопрос заключается в том, что в конечном состоянии C5 и C3 ' идентичны?

Или, скажем, git rebase равно git merge + удалить C3 ?

Answer 1

Пример не очень хороший, потому что он рассматривает только один коммит (объединенный или перебазированный), создавая впечатление, что полученные коммиты похожи. В целом, ребаз добавляет несколько коммитов, в то время как объединение добавляет не более одного (быстрое слияние не добавляет ни одного).

Более того, до тех пор, пока нет конфликта для разрешения или если вы решите указанные конфликты одинаково каждый раз , конечное содержимое C3 'и C5 будет то же самое, но они остаются разными коммитами (поскольку у C3 'и C5 разные родители, у них также будут разные хэши, что более очевидно на рисунках ниже). Соответственно записанная история у каждого разная. Примечание для ребаз, история линейная, а для слияния это решетка .

Рассмотрим тот же вопрос при слиянии / перебазировании нескольких коммитов , как показано в « A Visual Git Reference » от Марка Лодато. Вы увидите, что конечный результат будет совсем другим.

git checkout master
git merge other # update master with tip of branch 'other' changes

Вы берете только:

• текущий коммит (ed489 ниже, так как вы на мастере),
• последний коммит ветки other (который представляет собой моментальный снимок, представляющий полное содержимое репо, когда он разветвлен в 'other', а не в дельте)
• их общий предок (b325c) и выполняет трехстороннее слияние .

Для значения рабочего каталога и этапа на этой диаграмме обратите внимание на стрелки, идущие к трехстороннему объединению, затем к рабочему каталогу и этапу. В рабочем каталоге представлены все файлы, которые вы видите (на своем жестком диске), некоторые из которых были изменены в результате трехстороннего слияния. Этап содержит файлы, измененные в результате трехстороннего слияния, которое затем используется для создания нового коммита (f8bc5).

Это сильно отличается от перебазирования, которое стремится к повторному применению каждого коммита ветки поверх ветви назначения :

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, а затем перемещает головку ветки к новому наконечнику. Обратите внимание, что старые коммиты [со временем] будут собираться, если на них больше нет ссылок.

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

---

2 дополнительных отличия:

• Слияние и перебазирование служат различным рабочим процессам: см. « git merge vs. rebase »
• «наши» и «их» различны между слиянием и перебазированием: « Почему значения« наши »и« их »меняются местами »

Answer 2

Нет. C5 и C3 'будут иметь разные родительские коммиты, то есть они сами будут разными.

Если вы спрашиваете, будет ли корневая древовидная структура, на которую ссылаются C5 и C3 ', идентичны, тогда да (при условии, что любые конфликты были разрешены одинаково). Другими словами, дерево файлов, «содержащихся» в обеих фиксациях, будет одинаковым.

Answer 3

Если вы посмотрите только на содержание коммитов (то есть не на то, что являются их родителями), то и C5, и C3 'содержат одно и то же (при условии, что не было конфликтов слияния или других вещей, требующих изменения вручную).Так что кто-то может подумать, что он такой же, как если бы C3 был удален, для некоторого определения «удалить C3».Но в Git невозможно удалить любые коммиты (все коммиты являются неизменяемыми), поэтому операция удаления коммита из дерева не определена для Git.