Во-первых, давайте рассмотрим, что бы здесь делала обычная «перебазировка» в ветку релиза:
- git не знает, что задействовано
master, поэтому видит только две ветви: особенностьс коммитами a-b-1-2-3 и релизом с коммитами a-x-y-z - поэтому общая точка ветвления равна
a, так что коммиты, подлежащие перебазированию, будут b-1-2-3 - , новая ветвь будетв итоге получим
a-x-y-z-b-1-2-3, вставляя коммит (b), который на практике может быть большим фрагментом master
К счастью, команда git rebase имеет форму с тремя аргументами, которая страница справочника сводится к следующему:
git rebase --onto <newbase> <upstream> <branch>
Но, возможно, лучше объяснить это как:
git rebase --onto <new-parent> <old-parent> <branch>
В вашем примере:
<newbase> / <new-parent> будет коммитом (z): точка, на которую вы хотите получить коммиты, на <upstream> / <old-parent> будет коммитом (b): точка, где коммиты вас интересуютв текущей ветке от (текущий родитель первого коммита, который вас интересует) <branch> would будет именем ветви объекта, которая в данный момент указывает на (3), и которая вместо этого будет указывать на новую перебазированную историю
Вы можете пропустить последний аргумент, и он будет просто использоватькакая ветка в данный момент проверена;если указано, это должно быть имя ветви.Другими двумя аргументами могут быть все, что идентифицирует коммит - имя ветви, имя тега или просто хеш коммита.