Я не понимаю содержимое страницы https://sethrobertson.github.io/GitFixUm/fixup.html#move_commit:
Перемещение коммита из одной ветви в другую
Итак, у вас есть Коммит, который находится в неправильном месте, и вы хотите переместить его из одной ветви в другую. Для этого вам необходимо знать SHA первого и последнего коммита (в непрерывной серии коммитов), которые вы хотите переместить (эти значения одинаковы, если вы перемещаете только один коммит), имя ветвь, из которой вы перемещаете коммит, и название ветви, в которую вы перемещаете коммит. В приведенном ниже примере я назову эти четыре значения $ first, $ last, $ source и $ destination (соответственно). Кроме того, вам нужно использовать ветку nonce в качестве заполнителя. Я буду называть ветку nonce «nonce» в следующем примере. Однако вы можете использовать любое имя ветки, которое в данный момент не используется. Вы можете удалить его сразу же после того, как закончите.
git branch nonce $last
git rebase -p --onto $destination $first^ nonce
Помните, что когда вы подставляете $ first в вышеприведенной команде, оставьте «^» в покое, это буквально.
Использование gitk --all --date-order
проверить, чтобы убедиться, что движение выглядит правильно (делая вид, что одноразовый номер является ветвью назначения). Пожалуйста, проверьте очень внимательно, если вы пытаетесь переместить слияние, возможно, оно было воссоздано неправильно. Если вам не нравится результат, вы можете удалить ветвь nonce (git branch -D nonce
) и повторить попытку.
Однако, если все выглядит хорошо, мы можем переместить указатель фактической ветви назначения туда, где находится nonce:
git checkout $destination
git reset --hard nonce
git branch -d nonce
Если вы дважды проверите с gitk --all --date-order
, вы увидите, что ветвь назначения выглядит правильно. Тем не менее, коммиты все еще находятся в исходной ветке. Теперь мы можем избавиться от них:
git rebase -p --onto $first^ $last $source
Используя последний раз gitk --all --date-order
, вы должны увидеть, что коммиты в ветке-источнике исчезли. Вы успешно переместили коммиты. Пожалуйста, очень внимательно проверьте, произошли ли слияния после коммитов, которые были удалены. Возможно, они были воссозданы неправильно. Если это так, вы можете либо отменить удаление , либо попытаться удалить неудачное слияние и попытаться воссоздать его вручную, либо создать поддельное (--ours) слияние из того же SHA, чтобы git знало, что произошло слияние.
Я постараюсь объяснить, что я знаю, а что нет. Я был бы признателен, если бы кто-нибудь др aws дерево коммитов после каждой команды.
Во-первых,
git branch nonce $last (1)
git rebase -p --onto $destination $first^ nonce (2)
Как я понимаю (1) копирует коммит $ last в ветви с именем nonce , В (2) диапазон коммитов от $ first до nonce включительно перемещается поверх $ destination. Я не понимаю, как будет выглядеть дерево коммитов в этой точке, потому что я не совсем получаю эффект (1).
Затем
git checkout $destination (3)
git reset --hard nonce (4)
git branch -d nonce (5)
(3) проверок коммит из пункта назначения. Тогда в (4) hard сбрасывается в nonce, но каков эффект этого? Затем в (5) удалите ветку nonce.
Наконец,
git rebase -p --onto $first^ $last $source (6)
Текст говорит (6), что приводит к удалению коммитов в исходной ветке. Как я понимаю этот синтаксис, это помещает диапазон коммитов, определенных как потомки $ last, включая $ source поверх родительского $ first.
Я знаю синтаксис git rebase --onto
. Но я не понимаю, что именно здесь происходит.
Буду признателен, если вы поможете мне нарисовать диаграмму дерева коммитов после каждой команды.