Organizando o histórico com rebase (e a regra de ouro)
Este é o tópico mais confuso do curso, então vamos com calma. Na aula passada vimos o merge — uma forma de combinar o trabalho de um branch, que deixa um merge commit e mantém as duas linhagens exatamente como aconteceram. Agora conhecemos uma segunda forma, o git rebase: ele 'reproduz' os commits d
rebase é como pegar as páginas que você escreveu e recopiá-las no final do caderno atualizado da equipe — como se você as tivesse escrito ali desde o início. O resultado parece organizado e reto, mas são páginas novas. Por isso você não recopia páginas que já entregou para outras pessoas — elas ainda têm as páginas antigas, e isso cria confusão.
- git rebase
- Reproduz os commits do branch atual para que comecem a partir da ponta de outro branch, criando um histórico linear. Os commits originais são substituídos por commits novos, com hashes novos.
- Histórico linear
- Um histórico que é uma única linha reta de commits, sem bifurcações e sem merge commit — cada commit fica diretamente em cima do anterior.
- Regra de ouro
- Nunca faça rebase de commits que você já deu push ou já compartilhou com outras pessoas. O rebase reescreve hashes, então só é seguro em trabalho local e privado.
- Hash do commit
- O identificador único de cada commit (uma impressão digital). Se qualquer coisa no commit mudar — inclusive o parent dele — ele ganha um hash novo, e assim se torna um commit diferente.
- Replay (reprodução)
- A ação em que o rebase pega cada um dos seus commits e os reaplica, um por um, em cima da ponta do outro branch — é assim que os novos commits são criados.
