Как мне понять этот git rebase - на примере?

Question

Управление версиями с Git имеет пример

Чтобы трансплантировать коммиты P и Q в ветви функций из maint в главную ветвь, введите команду:

 $ git rebase --onto master maint^ feature

Дает ли следующая команда также тот же результат

git rebase --onto master maint feature

Почему в книге используется maint^ вместо maint?

Answer 1

Из-за нехватки времени я дам здесь только краткий ответ:

Дает ли следующая команда также тот же результат

git rebase --onto master maint feature

Для этого конкретного графика , да. Для (некоторых) других графиков нет. (Конечно, для других графиков они могли бы предложить другие команды.)

Почему в книге используется maint^ вместо maint?

Не будучи автором, я могу только догадываться. Эта конкретная форма git rebase соответствует первому синтаксису в разделе SYNOPSIS документации git rebase :

 git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>]
         [<upstream> [<branch>]]

Здесь они устанавливают newbase = master, upstream = maint^ и branch = feature. Так что это начнется с выполнения git checkout feature, а затем перечислит коммиты в maint^..HEAD, чтобы найти кандидатов для копирования. Если вы посмотрите на свой график, вы увидите, что он точно фиксирует P и Q: он начинается с Q, возвращается к P, оттуда к Y и Y * 1047. * is maint^.

Используя git rebase --onto master maint feature, Git начинал бы с Q, возвращался к P, возвращался к Y и все еще останавливался, потому что maint идентифицирует Z и возвращаясь от Z получает нам Y. Но это требует дополнительного шага от Z. Предположительно авторы не желали заставлять читателя сделать этот дополнительный шаг в его голове.

Answer 2

Форма git rebase с тремя аргументами –onto Скажем, есть ветка «topicA», которая в какой-то момент расходится с master:

A - B - C - D - E мастер

 F--G--H topicA

Давайте также скажем, что кто-то еще отошел от темы A, чтобы создать тему B, и добавил больше коммитов:

A - B - C - D - E master

 F--G--H topicA

         I--J--K--L--M topicB

Это пример реального случая, с которым я столкнулся, когда у themeA было всего пара очень больших коммитов, которые было трудно переварить и которые могли быть разбиты на множество более мелких коммитов. Тема B была создана как продолжение работы над темой A.

Я проверил свою собственную локальную копию topicA, и благодаря большому интерактивному перебазированию и изумительному использованию git add -e, я смог разделить topicA на коммиты меньшего размера, сделав topicC:

A - B - C - D - E мастер | | F - G - H тема A | | Я - J - K - L - M тема B | N - O - P - Q - R - S - T - U - V - W тема C

Я разговаривал с человеком, который создал тему A, и мы согласились с тем, что моя ветка themeC должна занять место themeA. Но что делать с работой, проделанной над темой B?

Операция, которую мы хотели сделать, состоит в том, чтобы сделать topicC новой основой темы B, вырезав ее в точке тема B, отличной от темы A, которая выглядит следующим образом:

A - B - C - D - E мастер | | F - G - H тема A | | I - J - K - L - M тема B

 N--O--P--Q--R--S--T--U--V--W--I'--J'--K'--L'--M' topicC

Пять коммитов из темы B (от I до M) воспроизводятся поверх темы C, начиная с того, где тема B расходится с темой A, для создания I ’, J’, K ’, L’ и M ’.

Команда для этого:

git rebase --onto topicC topicA topicB

Если topicC - это новая база, topicA - старая база, а topicB - это ссылка на то, чем станет HEAD темы C.

Итак, ваш ответ: да, его можно использовать без ^

Значение ^:

HEAD ^ означает первого родителя кончика текущей ветви.

Помните, что коммиты git могут иметь более одного родителя. HEAD ^ - это сокращение от HEAD ^ 1, и вы также можете обращаться к HEAD ^ 2 и т. Д. В зависимости от ситуации.

Вы можете получить к родителям любой коммит, а не только ГОЛОВУ. Вы также можете перемещаться назад через поколения: например, master ~ 2 означает прародителя кончика основной ветви, отдавая предпочтение первому родителю в случаях неоднозначности. Эти спецификаторы могут быть связаны произвольно, например, тема ~ 3 ^ 2.