Git rebase: tudo o que você precisa saber
Publicados: 2022-12-15
O comando Git rebase combina duas ramificações de código-fonte em uma. O comando Git merge também faz isso. Explicamos o que o rebase faz, como é usado e quando usar a merge .
A explosão do Git
O que é Git merge?
O que é Git rebase?
Como fazer rebase em outra ramificação
Git Rebase vs. Merge: qual você deve usar?
Rebasear ou não rebasear?
A explosão do Git
Frustrado com outros sistemas de controle de versão e suas atualizações e confirmações lentas, Linus Torvalds, famoso pelo kernel do Linux, reservou um mês em 2005 para escrever o seu próprio. Ele o chamou de Git.
Sites como GitHub, GitLab e BitBucket promoveram simbioticamente e se beneficiaram do Git. Hoje, o Git é usado globalmente, com 98% dos 71 mil entrevistados em uma pesquisa de 2022 usando o Git como sistema de controle de versão.
Uma das principais decisões de design do Git foi a velocidade. Em particular, trabalhar com filiais tinha que ser o mais rápido possível. Branches são uma parte fundamental dos sistemas de controle de versão. Um repositório de projeto terá uma ramificação principal ou principal. É aqui que fica a base de código do projeto. O desenvolvimento, como novos recursos, ocorre em ramificações laterais segregadas. Isso impede que o trabalho feito nas ramificações estrague a ramificação principal e permite que o desenvolvimento simultâneo ocorra em diferentes partes da base de código.
À medida que os desenvolvimentos nas ramificações laterais são concluídos, as alterações são transferidas para a ramificação principal, mesclando a ramificação de desenvolvimento na ramificação principal. Em outros sistemas de controle de versão, trabalhar com branches era difícil e computacionalmente caro. Trabalhar com branches no Git é muito rápido e muito leve. O que antes era um exercício tedioso e muitas vezes evitado em outros sistemas, tornou-se trivial no Git.
O comando Git rebase é outra forma de transferir as alterações de um branch para outro branch. Os comandos merge e rebase têm objetivos semelhantes, mas atingem seus fins de maneiras diferentes e produzem resultados ligeiramente diferentes.
O que é Git merge?
Então, para que serve o comando Git merge ? Digamos que você criou uma ramificação chamada dev-branch para trabalhar em um novo recurso.
Você faz alguns commits e testa seu novo recurso. Tudo funciona bem. Agora você deseja enviar seu novo recurso para a ramificação master . Você deve estar na ramificação master para mesclar outra a ela.
Podemos garantir que estamos na ramificação master verificando-a explicitamente antes de mesclarmos.
mestre de checkout git
Agora podemos dizer ao Git para mesclar o dev-branch no branch atual, que é o branch master .
git merge dev-branch
Nossa merge está concluída para nós. Se você verificar o branch master e compilá-lo, ele terá o recurso recém-desenvolvido. O que o Git realmente realizou foi uma mesclagem de três vias. ele compara os commits mais recentes nos branches master e dev-branch , e o commit no branch master imediatamente antes do dev-branch ser criado. Em seguida, ele executa um commit na ramificação master .
As fusões são consideradas não destrutivas porque não excluem nada e não alteram nada do histórico do Git. O dev-branch ainda existe e nenhum dos commits anteriores foi alterado. Uma nova confirmação é criada para capturar os resultados da mesclagem de três vias.
Após a fusão, nosso repositório Git se parece com uma linha do tempo com uma ramificação de linha alternativa e, em seguida, retornando à linha do tempo principal.
O dev-branch foi incorporado ao branch master .
Se você tiver muitas ramificações em um projeto, o histórico do projeto pode se tornar confuso. Geralmente, esse é o caso se um projeto tiver muitos colaboradores. Como o esforço de desenvolvimento se divide em muitos caminhos diferentes, o histórico de desenvolvimento não é linear. Desvendar o histórico de commits torna-se ainda mais difícil se os branches tiverem seus próprios branches.
Observe que, se você tiver alterações não confirmadas na ramificação master , precisará fazer algo com essas alterações antes de mesclar qualquer coisa com ela. Você pode criar uma nova ramificação e confirmar as alterações lá e, em seguida, fazer a mesclagem. Em seguida, você precisaria mesclar sua ramificação temporária de volta à ramificação principal.
Isso funciona, mas o Git tem um comando que faz a mesma coisa, sem precisar criar novos branches. O comando stash armazena suas alterações não confirmadas para você e permite que você as chame de volta com stash pop .
Você os usaria assim:
esconder git merge dev-branch esconderijo pop
O resultado final é um branch mesclado, com suas alterações não salvas restauradas.
O que é Git rebase?
O comando rebase do Git atinge seus objetivos de uma maneira completamente diferente. Ele pega todos os commits do branch que você vai fazer o rebase e os repete no final do branch no qual você está fazendo o rebase.
Tomando nosso exemplo anterior, antes de executarmos qualquer ação, nosso repositório Git se parece com isso. Temos uma ramificação chamada dev-branch e queremos mover essas alterações para a ramificação master .
Após o rebase , parece uma linha do tempo única e completamente linear de alterações.
O dev-branch foi removido e os commits no dev-branch foram adicionados ao master. O resultado final é o mesmo como se os commits no dev-branch tivessem realmente sido confirmados diretamente no branch master em primeiro lugar. Os commits não são apenas adicionados ao branch master , eles são “repetidos” e adicionados novos.
É por isso que o comando rebase é considerado destrutivo. O branch rebaseado não existe mais como um branch separado, e o histórico Git do seu projeto foi reescrito. Você não pode determinar em algum momento posterior quais commits foram originalmente feitos para o dev-branch .
No entanto, deixa você com uma história simplificada e linear. Comparado a um repositório com dezenas ou mesmo centenas de branches e merges, lendo o log do Git ou usando uma GUI git gráfica para ver um gráfico do repositório, um repositório rebaseado é muito fácil de entender.
Como fazer rebase em outra ramificação
Vamos tentar um exemplo de git rebase . Temos um projeto com uma ramificação chamada new-feature . Faríamos o rebase desse branch para o branch master assim.
Primeiro, verificamos se o branch master não possui alterações pendentes.
git status
Verificamos a ramificação new-feature .
git checkout novo recurso
Dizemos ao Git para rebase o branch atual no branch master.
git rebase mestre
Podemos ver que ainda temos dois ramos.
ramo git
Trocamos de volta para o branch master
mestre de checkout git
Nós mesclamos o branch de novos recursos com o branch atual, que em nosso caso é o branch master .
git merge novo recurso
Curiosamente, ainda temos duas ramificações após a mesclagem final.
A diferença é que agora o cabeçalho do branch de new-feature e o cabeçalho do branch master estão definidos para apontar para o mesmo commit, e o histórico do Git não mostra que costumava haver um branch new-feature separado, além de a etiqueta do ramo.
Git Rebase vs. Merge: qual você deve usar?
Não é um caso de rebase vs. merge . Ambos são comandos poderosos e você provavelmente os usará. Dito isso, há casos de uso em que o rebase não funciona muito bem. Unpicking erros causados por erros usando merge são desagradáveis, mas unpicking erros causados por rebase é infernal.
Se você é o único desenvolvedor usando um repositório, há menos chance de você fazer algo desastroso com o rebase . Você ainda pode rebase na direção errada, por exemplo, e rebase sua ramificação master para sua ramificação new-feature . Para obter seu branch master de volta, você precisa fazer o rebase novamente, desta vez de seu branch de new-feature para seu branch master . Isso restauraria seu branch master , embora com um histórico de aparência estranha.
Não use rebase em branches compartilhados onde outras pessoas provavelmente trabalharão. Suas alterações em seu repositório causarão problemas para muitas pessoas quando você enviar seu código rebaseado para seu repositório remoto.
Se o seu projeto tiver vários contribuidores, a coisa mais segura a fazer é usar o rebase apenas em seu repositório local e não em branches públicos. Da mesma forma, se as solicitações pull fizerem parte de suas revisões de código, não use rebase . Ou, pelo menos, não use rebase depois de criar a solicitação pull. É provável que outros desenvolvedores estejam olhando para seus commits, o que significa que essas alterações estão em um branch público, mesmo que não estejam no branch master .
O perigo é que você vai rebase commits que já foram enviados para um repositório remoto, e outros desenvolvedores podem já ter baseado o trabalho nesses commits. Seu rebase local fará com que os commits existentes desapareçam. Se você enviar essas alterações para o repositório, não será popular.
Outros contribuidores terão que passar por uma merge confusa para que seu trabalho seja enviado de volta ao repositório. Se você puxar as alterações de volta para o repositório local, terá que desfazer uma confusão de alterações duplicadas.
Rebasear ou não rebasear?
Rebase pode ser proibido em seu projeto. Pode haver objeções locais e culturais. Alguns projetos ou organizações consideram o rebase uma forma de heresia e um ato de profanação. Algumas pessoas acreditam que a história do Git deve ser um registro inviolável e permanente do que aconteceu. Portanto, o rebase pode estar fora de questão.
Mas, usado localmente, em ramificações privadas, o rebase é uma ferramenta útil.
Faça push depois de rebasear e restrinja-o a branches onde você é o único desenvolvedor. Ou, pelo menos, onde todo o desenvolvimento parou e ninguém mais baseou qualquer outro trabalho nos commits do seu branch.
Faça isso e evitará problemas.
RELACIONADO: Como verificar e atualizar sua versão do Git