Разница между 'rebase master' и 'rebase --onto master' из ветви, полученной из ветви master

Когда вы перебазируете коммиты, вы фактически копируете эти коммиты.

Git никогда не может изменить какой-либо коммит.

Есть одно «истинное имя» для любого коммита (или даже любого объекта в репозитории git), которое является его SHA-1: эта строка из 40 шестнадцатеричных цифр, такая как 9f317ce..., который вы видите в git log, например. SHA-1 представляет собой криптографическую ^{1 контрольную сумму содержимого объекта. Содержимое содержит информацию об авторе и коммиттере (имя и адрес электронной почты), метки времени, исходное дерево и список родительских коммитов. Родителем коммита №7 всегда является коммит №5. Если вы делаете в основном точную копию коммита # 7, но устанавливаете его родительский коммит # 2 вместо коммита # 5, вы получаете другой коммит с другим идентификатором. (У меня заканчиваются однозначные цифры - обычно я использую заглавные буквы для представления идентификаторов фиксации, но с ветвями с именами A и B я подумал, что это сбивает с толку. Поэтому я назову копию # 7, # 7a, ниже.)}

Что git rebase делает

Когда вы просите git перебазировать цепочку коммитов - например, коммиты # 7-8-9 выше - он имеет скопировать их , по крайней мере, если они собираются куда-то двигаться (если они не двигаются, они могут просто оставить оригиналы на месте). По умолчанию он копирует коммиты из проверенной в данный момент ветки, поэтому git rebase требуется только две дополнительные части информации:

• Какие коммиты следует скопировать?
• Где должен копирует землю? То есть, каков целевой родительский идентификатор для первого скопированного коммита? (Дополнительные коммиты просто указывают на первое скопированное, второе скопированное и т. Д.)

Когда вы запускаете git rebase <upstream>, вы позволяете git вычислять обе части из одного фрагмента информации. , Когда вы используете --onto, вы получаете возможность рассказать git отдельно об обеих частях: вы все еще предоставляете upstream, но он не вычисляет цель из <upstream>, он только вычисляет коммиты для копирования из <upstream>. (Между прочим, я думаю, что <upstream> не является хорошим именем, но это то, что использует rebase, и у меня нет ничего лучше, поэтому давайте придерживаться этого здесь. Rebase вызывает target <newbase>, но Я думаю, что target - гораздо лучшее имя.)

Давайте сначала рассмотрим эти два варианта. Оба предполагают, что вы находитесь на ветке B в первую очередь:

1. git rebase master
2. git rebase --onto master A
[11127]

С первой командой аргументом <upstream> для rebase является master. Со вторым это A.

Вот как git вычисляет, который выполняет копирование: он передает текущую ветвь в git rev-list , а также передает <upstream> в git rev-list, но с использованием --not - или, точнее, с эквивалентом двухточечной нотации exclude..include. Это означает, что нам нужно знать, как работает git rev-list.

Хотя git rev-list чрезвычайно сложно - большинство команд git заканчивают тем, что используют его; это движок для git log, git bisect, rebase, filter-branch и т. д. - этот конкретный случай не слишком сложен: в двухточечной нотации rev-list перечислены все коммиты, достижимые справа. со стороны (включая этот коммит), исключая каждый коммит, достижимый с левой стороны.

В этом случае git rev-list HEAD находит все коммиты, достижимые из HEAD, то есть почти все коммиты: коммиты 0-5 и 7-9, а git rev-list master находит все коммиты, достижимые из master, который Фиксация # 0, 1 и 2. Вычитание 0-через-2 из 0-5,7-9 оставляет 3-5,7-9. Это кандидат обязуется скопировать, как указано в git rev-list master..HEAD.

Для нашей второй команды у нас есть A..HEAD вместо master..HEAD, поэтому коммиты для вычитания равны 0-6. Коммит № 6 не появляется в наборе HEAD, но это нормально: вычитая что-то, чего нет, оставляет его там. Таким образом, число получаемых кандидатов на копирование равно 7-9.

Это все еще оставляет нас с определением цели перебазирования, то есть, где должен быть скопирован коммит земли? Для второй команды ответом является «фиксация, определенная аргументом --onto». Поскольку мы сказали --onto master, это означает, что целью является коммит №2.

rebase # 1

git rebase master

Однако с помощью первой команды мы не указали цель напрямую, поэтому git использует фиксацию, идентифицированную <upstream>. <upstream>, которое мы дали, было master, которое указывает на коммит №2, поэтому целью является коммит №2.

Поэтому первая команда будет начинаться с копирования коммита # 3 с любыми минимальными изменениями, необходимыми для того, чтобы его родитель был коммитом № 2. Его родителем является уже коммит # 2. Ничего не должно меняться, поэтому ничего не меняется, и rebase просто повторно использует существующий коммит # 3. Затем он должен скопировать # 4, чтобы его родитель # 3, но родитель уже # 3, поэтому он просто повторно использует # 4. Точно так же # 5 это уже хорошо. Он полностью игнорирует # 6 (это не входит в набор коммитов для копирования); он проверяет # 7-9, но все они тоже хороши, так что вся перебазировка заканчивается просто повторным использованием всех оригинальных коммитов. В любом случае вы можете принудительно копировать копии с -f, но вы этого не сделали, поэтому весь этот перебаз в конечном итоге ничего не делает.

rebase # 2

git rebase --onto master A

Вторая команда rebase использовала --onto для выбора # 2 в качестве своей цели, но сказала git для копирования только что зафиксировала 7-9. Родителем коммита # 7 является коммит №5, поэтому эта копия действительно должна что-то делать. ^{2 Таким образом, git делает новый коммит - давайте назовем это # ​​7a - который имеет коммит № 2 в качестве родителя. Перебазировка переходит к фиксации # 8: копии теперь требуется # 7a в качестве ее родителя. Наконец, rebase переходит к коммиту # 9, которому нужен # 8a в качестве родителя. Со всеми скопированными коммитами последнее, что делает rebase, это перемещает метку (помните, метки перемещаются и меняются!). Это дает график, подобный следующему:}

          7a - 8a - 9a       <-- HEAD=B
         /
0 - 1 - 2                    <-- master
         \
          3 - 4 - 5 - 6      <-- A
                    \
                     7 - 8 - 9   [abandoned]

Хорошо, но как насчет git rebase --onto master A B?

Это почти то же самое, что и git rebase --onto master A. Разница в том, что дополнительные B в конце. К счастью, эта разница очень проста: если вы дадите git rebase один дополнительный аргумент, сначала он запускает git checkout для этого аргумента. ³

Ваши исходные команды

В своем первом наборе команд вы выполнили git rebase master, находясь на ветке B ]. Как отмечалось выше, это большой запрет: так как ничего не нужно перемещать, git вообще ничего не копирует (если вы не используете -f / --force, чего вы не делали). Затем вы проверили master и использовали git merge B, который - если это сказано ^{4 - создает новый коммит с слиянием. Поэтому Ответ Дерика , по крайней мере, на тот момент, когда я его видел, является правильным: коммит слияния имеет двух родителей, один из которых является вершиной ветви B, и эта ветвь проходит через три коммиты, которые находятся на ветке A и, следовательно, некоторые из того, что на A, в конечном итоге объединяются в master.}

Со своей второй последовательностью команд вы сначала извлекли B (вы уже были на B, так что это было избыточно, но было частью git rebase). Затем вам пришлось перебазировать копию трех коммитов, получая последний график выше, с коммитами 7a, 8a и 9a. Затем вы проверили master и сделали коммит слияния с B (снова см. Сноску 4). Опять же, ответ Дерика правильный: единственное, чего не хватает, так это того, что исходные, оставленные коммиты не затянуты, и не так очевидно, что новые объединенные коммиты являются копиями.

---

^{1 Это имеет значение только в том смысле, что чрезвычайно сложно нацелиться на конкретную контрольную сумму. То есть, если кто-то , которому вы доверяете, скажет вам: «Я доверяю коммиту с идентификатором 1234567 ...», для кого-то еще - кого-то, кому вы не так доверяете, почти невозможно придумать коммит, который имеет тот же идентификатор, но имеет другое содержимое. Вероятность того, что это произойдет случайно, составляет 1 к 2 160 , что намного меньше вероятности того, что у вас случится сердечный приступ при ударе молнии при утоплении в цунами при похищении космическими инопланетянами. : -)}

^{2 Фактическая копия сделана с использованием эквивалента git cherry-pick : git сравнивает дерево коммита с деревом его родителя, чтобы получить diff, затем применяет diff к дереву нового родителя.}

^{3 Это на самом деле, на самом деле, в настоящий момент буквально верно: git rebase - это сценарий оболочки, который анализирует ваши параметры, а затем решает, какой тип внутренней перебазировки выполнить: неинтерактивный git-rebase--am или интерактивный git-rebase--interactive. После выяснения всех аргументов, если есть один оставшийся аргумент имени ветви, скрипт выполняет git checkout <branch-name> перед началом внутренней ребазировки.}

^{4 Поскольку master указывает на коммит 2, а коммит 2 является прародителем коммита 9, он обычно не делает коммит слияния в конце концов, а вместо этого делает то, что Git называет перемотка вперед . Вы можете указать Git не выполнять эти перемотки вперед, используя git merge --no-ff. Некоторые интерфейсы, такие как веб-интерфейс GitHub и, возможно, некоторые графические интерфейсы, могут разделять различные виды операций, так что их «объединение» вызывает истинное слияние, подобное этому.}

При слиянии в ускоренном режиме последний граф для первого случая выглядит следующим образом:

0 <- 1 <- 2         [master used to be here]
           \
            3 <- 4 <- 5 <- 6      <------ A
                       \
                        7 <- 8 <- 9   <-- master, HEAD=B

В любом случае коммиты с 1 по 9 теперь находятся на обеих ветвях , master и B. Разница по сравнению с истинным слиянием заключается в том, что на графике вы можете увидеть историю, которая включает слияние.

Другими словами, преимущество ускоренного слияния состоит в том, что оно не оставляет следов того, что в противном случае является тривиальной операцией. Недостаток быстрого слияния состоит в том, что он не оставляет следов. Таким образом, вопрос о том, разрешить ли быструю перемотку вперед, действительно является вопросом о том, хотите ли вы оставить явное слияние в истории, сформированной коммитами.