Eu tenho um repositório git com um histórico local linear de, digamos, 10 commits, onde os primeiros 5 estão no branch1
histórico de e os últimos 5 commits estão no branch2
histórico de e quero corrigir as descrições/autor/data /other propriedades desses dez commits, alterando-os. A situação seria assim:
---(old history)---A--B--C--D--E--F--G--H--I--J
^ ^
| |
branch1 branch2
Não tenho certeza sobre como proceder aqui. Posso pensar em duas estratégias para fazer o que quero, mas quero primeiro compreender seus efeitos potenciais.
em vez de fazer um rebase interativo mais longo de 10 commits, prefiro mudar para
branch1
primeiro, fazer um rebase interativo nos últimos 5 commits e, quando terminar, mudarbranch2
e fazer um rebase interativo dos últimos 5 commits. Mas como o rebase implica na criação de novos commits em um "novo branch", não sei o que aconteceria com o pai do HEAD dobranch1
. A questão é : essa estratégia criará algum tipo de estado estranho como este (vamos chamarbranch1'
o novo branch após o rebase):---(old history)---?--?--?--?--?--F--G--H--I--J | ^ ^ | | | | branch1(???) branch2(???) | | --A--B--C--D--E ^ | branch1'
ou o git consertará o pai
F
da maneira certa?A outra estratégia é mudar
branch2
e fazer um rebase interativo dos seus últimos 10 commits diretamente; mas, novamente, a questão é : para onde o HEADbranch1
apontará depois do rebase? Para um commit que não está mais nabranch2
história?
Seus diagramas indicam um mal-entendido fundamental que deve ser esclarecido. Se você começar com:
e faça um rebase interativo (por exemplo
git checkout branch1; git rebase -i A^
), o diagrama de commit será semelhante a:Depois de fazer isso, você pode simplesmente fazer:
e você terá:
com branch1 em
E'
e branch2 emJ'
. Supondo que seu primeiro rebase interativo realmente tenha alterado os metadados do commit, não deverá haver conflitos de mesclagem. Depois disso (ou pela primeira vez), você pode fazergit rebase -i branch1
(supondo que ainda tenha feitobranch2
check-out) para obter:Uma coisa importante a lembrar é que os commits são imutáveis. Quando você faz um rebase, novos commits são criados, mas os antigos não são (imediatamente) deletados. (Eles podem ser limpos em uma coleta de lixo executada posteriormente, mas a menos que você tenha alterado algumas configurações padrão, isso não acontecerá por algumas semanas.) Ramos, entretanto, são muito mutáveis. Por exemplo, toda vez que você faz um commit, a ponta do branch muda para se referir ao novo commit. A presença de
branch1'
no seu diagrama sugere que este ponto não é bem compreendido.