Em breve, dado:
Before rebase After rebase
A---B---C---F---G (branch) A---B---C---F---G (branch)
\ \ \
D---E---H---I (HEAD) \ E'---H' (HEAD)
\
D---E---H---I
git rebase --onto F D H
Qual é o mesmo que (porque --ontoleva um argumento):
git rebase D H --onto F
Significa rebase commit no intervalo (D, H] em cima de F. Observe que o range é exclusivo à esquerda. É exclusivo porque é mais fácil especificar o 1º commit digitando, por exemplo, branchpara deixar gitencontrar o 1º commit divergente, branchou seja, o Dque leva a H.
Caso OP
o---o (A)
\
o (B)(HEAD)
git checkout B
git rebase --onto B A
Pode ser alterado para um único comando:
git rebase --onto B A B
O que parece erro aqui é o posicionamento, Bque significa "mover alguns commits que levam a ramificação Bpor cima B". A questão é o que "alguns commits" são. Se você adicionar -isinalizador, verá que é um único commit apontado por HEAD. A confirmação foi ignorada porque já foi aplicada ao --ontodestino Be, portanto, nada acontece.
O comando não faz sentido, em qualquer caso em que o nome do ramo seja repetido assim. Isso ocorre porque o intervalo de confirmações será de algumas confirmações que já estão nessa ramificação e, durante a reformulação, todas elas serão ignoradas.
Mais explicações e uso aplicável de git rebase <upstream> <branch> --onto <newbase>.
git rebase padrões.
git rebase master
Expande para:
git rebase --onto master master HEAD
git rebase --onto master master current_branch
Check-out automático após o rebase.
Quando usado de maneira padrão, como:
git checkout branch
git rebase master
Você não notará que, após o rebase, gitpassar branchpara o commit rebased mais recente e o faz git checkout branch(consulte o git refloghistórico). O que é interessante quando o segundo argumento é o hash de confirmação, em vez disso, a rebase do nome da ramificação ainda funciona, mas como não há ramificação a ser movida, você acaba em "HEAD desanexado" em vez de fazer check-out na ramificação movida.
Omita confirmações divergentes primárias.
O masterin --ontoé retirado do 1º git rebaseargumento.
git rebase master
/ \
git rebase --onto master master
Tão prático que pode ser qualquer outro commit ou ramo. Dessa forma, você pode limitar o número de confirmações de rebase, pegando as mais recentes e deixando as confirmações divergentes primárias.
git rebase --onto master HEAD~
git rebase --onto master HEAD~ HEAD # Expanded.
Vai rebase única confirmação apontado por HEADque mastere acabam em "CABEÇA destacada".
Evite checkouts explícitos.
O padrão HEADou current_branchargumento é contextualmente retirado do local em que você está. É por isso que a maioria das pessoas faz checkout para ramificar as quais deseja refazer. Mas quando o segundo argumento de rebase é fornecido explicitamente, você não precisa fazer check-out antes de rebase para passá-lo de maneira implícita.
(branch) $ git rebase master
(branch) $ git rebase master branch # Expanded.
(branch) $ git rebase master $(git rev-parse --abbrev-ref HEAD) # Kind of what git does.
Isso significa que você pode recuperar as confirmações e ramificações de qualquer lugar. Então, juntamente com o checkout automático após o rebase.você não precisa fazer check-out separado da ramificação rebatida antes ou depois da rebase.
(master) $ git rebase master branch
(branch) $ # Rebased. Notice checkout.
