Когда вы добавили коммит i к вашему Branch-A, вы получите:
a -- b -- c ------ h <-- Master
\
d -- e -- i <-- Branch-A
\
f -- g <-- Branch-B
(Помните, ваш исходный чертеж содержит коммит h, поэтому он должен быть там до происходит слияние.) Фактическое слияние создает новый коммит j:
a -- b -- c ------ h -- j <-- Master
\ /
d -- e -- i <-- Branch-A
\
f -- g <-- Branch-B
Это слияние требуется , поскольку существующий коммит h должен быть сохранен,в то время как новые коммиты d-e-i становятся доступными из кончика master: для этого требуется коммит слияния j, чьи родители являются двумя существующими коммитами h и i.(Если бы h не существовало, то была бы возможна операция ускоренной перемотки вперед: это изменяет результирующую форму графика, поэтому его эффект будет распространяться до конца этого ответа. Предположим, что h существует, и / или вы принудительно)в любом случае, слияние без ускоренной перемотки.)
На данный момент у вас есть опция из , полностью удаляющая имя Branch-A (в любое время),а также опция копирования существующих коммитов f и g в новые и улучшенные коммиты f' и g'.Вы спрашиваете об этом ребазе.
Стоит ли ребазировать их?Это сложный вопрос.Но, если все остальные согласны с тем, что оригинальные коммиты f и g могут быть отменены в пользу новых и улучшенных f' и g', это нормально.Это может также сделать вещи красивее позже.Если вы решите не перебрасывать их, вопрос о том, как это сделать, является спорным.
Если вы do решите перебазировать их, ваш следующий вопрос должен быть: на каком целевом коммите?Должен ли f' идти после i или после j?Давайте нарисуем оба сценария:
(option 1: after i)
a -- b -- c ------ h -- j <-- Master
\ /
d -- e -- i <-- Branch-A
\ \
\ f' -- g' <-- Branch-B
\
f -- g [abandoned]
(option 2: after j)
f' -- g' <-- Branch-B
/
a -- b -- c ------ h -- j <-- Master
\ /
d -- e -- i
\
f -- g [abandoned]
Чтобы реализовать вариант 2, запустите:
git checkout Branch-B
git rebase Master
(я предпочитаю использовать две отдельные команды здесь, но вы можете записать это git rebase Master Branch-B, еслиВам нравится: дополнительный аргумент Branch-B заставляет git rebase начинаться с запуска сначала git checkout. Обратите внимание, что я удалил имя Branch-A: оно нам здесь не понадобилось.Вы можете или не можете удалить его на этом этапе, а если нет, то можете удалить его позже.
Чтобы сделать вариант 1, запустите:
git checkout Branch-B
git rebase Branch-A
На этот раз нам нужно name Branch-A, чтобы легко найти хеш-идентификатор commit j.Поэтому, если вы хотите, чтобы вариант 1 был реализован, и не хотели запускать git log и вырезать и вставлять хэш-идентификаторы, сохраняйте имя Branch-A как минимум до этого момента.После того, как перебазирование закончится, нам больше не нужно имя Branch-A, и теперь его можно безопасно удалить.
Технически , нам оно также не понадобилось до перебазирования, потому чтомы можем найти хеш-идентификатор j в любое время: git log Master начинается с j и показывает нам это, затем показывает нам один из h или i, и в конце концов мы видим i и, следовательно, видимего хэш-идентификатор.Таким образом, мы можем найти трудный путь, несмотря ни на что, но если вы сохраните имя на некоторое время, у нас не будет , чтобы сделать это.
Примечание: Если вы используете кликающие кнопки GitHub для «перебазирования и слияния» или «сквоша и слияния», эти не не выполняют стандартное слияние.Вместо этого они copy фиксируют новые, похожие на rebase.То есть они будут делать новые и предположительно улучшенные копии коммитов, которые вы пытаетесь включить.В этом случае ни одно из ваших существующих имен не находит правильных хеш-идентификаторов фиксации больше , потому что все ваши имена все еще помнят ваши исходные коммиты с их хеш-идентификаторамиа не те копии / новые коммиты, которые сделал GitHub.Поэтому, если вы делаете , используете более интересные операции GitHub, вам нужно будет запустить git fetch, чтобы получить новые коммиты из GitHub, затем использовать другие имена или необработанные хэш-идентификаторы коммитов;Вам следует в скором времени отбросить или исправить свои собственные имена веток, чтобы не запутаться в том, какие коммиты были оригиналами, а какие - новыми и предположительно улучшенными копиями.(Коммит f9131d9 оригинал или 70abf32c? А как насчет a31cf2a против 0449acd? Хеш-идентификаторы выглядят совершенно случайными, и сохранять их прямыми - это ... не весело.)