Desista de usar o Merge e abrace o Rebase com alegria!

1. Introdução

Olá a todos, eu sou o Bittao. Como a ferramenta de gerenciamento de versão mais popular, o Git deve ser usado por todos no processo de desenvolvimento. Como muitas operações no Git são executadas pelo Merge por padrão e é relativamente menos sujeito a erros, muitas pessoas usarão o Merge para mesclar o código. No entanto, como um dos principais comandos do Git, o Rebase ainda precisa ser entendido e utilizado em cenários adequados.

2. O papel do Rebase

Rebase Tradução chinesa: 变基, Acho que esta tradução é bastante contundente, fazendo com que muitas pessoas não entendam completamente o significado de rebase. Pessoalmente, quero dizer com Rebase 认爸爸, por exemplo, você pode rebase para o ramo de Papa Ma e se tornar seu herdeiro razoável.

A figura acima mostra uma situação de rebase.Você pode ver o efeito final como se o branch Feature não existisse, e o Commit recém-submetido parece que foi realmente submetido no branch principal. E se usarmos Merge, um nó de mesclagem será gerado:

pode não ser nada ver o nó Commit gerado por apenas uma mesclagem, mas há uma grande probabilidade de que fique assim no projeto atual: é

um lote confuso , como se estivesse vendo o nó Commit há muitos anos Um monte de código escrito por outras pessoas, o que, o que, o que é isso! Por outro lado, olhe para projetos reais desenvolvidos com Rebase. Não há mal sem comparação:

É por isso que You Yuxi também recomenda o uso de rebase:

3. Como usar o Rebase

De fato, muitas pessoas não usam o Rebase.Por um lado, elas não entendem como usá-lo na colaboração real do projeto. Por outro lado, já usei, mas tem muitos problemas, então penso erroneamente que não é fácil de usar e nunca mais uso. Deixe-me compartilhar aqui o processo colaborativo de Rebase que adotei recentemente ao trabalhar em um projeto (para fins de ilustração, ele foi adequadamente simplificado):

3.1 Check-out

Em primeiro lugar, se quisermos desenvolver novas funções ou corrigir bugs do branch master, precisamos fazer o checkout de um branch. Por exemplo,
verifique a ramificação dev no nó A, para tornar a cena mais complicada, após git checkout dev a ramificação. Algumas pessoas continuam submetendo B e C no mestre, formando a seguinte estrutura do Git:

Quero enfatizar aqui que muitas pessoas têm problemas com rebase porque querem que o branch seja rebase para ser um branch público. Na verdade, o dev aqui deve ser adequado apenas para o branch que você usa. Lembre-se de que o próprio Git é um gerenciamento de versão distribuído. De fato, o controle de versão pode ser feito muito bem sem warehouses remotos.Precisamos distinguir os conceitos de branches locais e branches remotos, que não estão diretamente relacionados. Então você pode apenas fazer uma ramificação NB em sua máquina local. Após o rebase, ninguém saberá qual nome fantasma você deu a si mesmo.

3.2 Gerenciamento Remoto

Se nossa própria ramificação de desenvolvimento não for necessariamente desenvolvida em um computador, para desenvolvermos em vários computadores por nós mesmos, podemos associar um armazém remoto próprio. Esta etapa é opcional.

3.3 Iniciar o rebase

Agora desenvolvemos D e E em dev, e então dev rebase masterformamos A, B, C, D, E:

embora pareça ser uma linha reta aqui, na verdade apenas dev sabe que seu pai se tornou mestre, mas mestre não reconhece este filho. Portanto, também precisamos: master merge dev, para que uma linha reta perfeita seja formada no mestre:

Finalmente, vá git push origin masterpara a ramificação remota para concluir este desenvolvimento.

3.4 Cuidados posteriores

Após o rebase, o dev mudou de base, o que equivale a reconhecer o ladrão como o pai, e agora quer reconhecê-lo novamente? Não pense nisso! Portanto, só pode ser resolvido à força, forçando o push para seu próprio warehouse remoto no branch não protegido: git push --force origin dev, e finalmente rebase dev para seu próprio branch remoto: git rebase origin dev, para facilitar a manutenção de seu próprio warehouse remoto. Até agora, o desenvolvimento na forma de rebase foi concluído e o próximo desenvolvimento pode ser continuado.

4. Vantagens e desvantagens do Rebase

Deixe-me falar sobre as vantagens primeiro:

• Mantenha o histórico de commits linear: Ao mesclar branches com merge, um novo commit de merge é criado, formando assim um novo branch no histórico de commits. Com o rebase, o registro de confirmação pode ser adicionado diretamente ao final da ramificação de destino, mantendo assim a linearidade do histórico de confirmação.
• Reduza envios de mesclagem desnecessários: ao usar a mesclagem para mesclar ramificações, um novo envio de mesclagem será criado, o que pode conter muitas informações de mesclagem sem sentido. Com o rebase, os registros de commit podem ser adicionados ao final da ramificação de destino um a um, evitando a criação de commits de mesclagem desnecessários.
• Melhor revisão e rastreabilidade do código: com o rebase, o histórico de confirmação pode se tornar mais intuitivo e compreensível, facilitando a revisão do código e a rastreabilidade do problema.
• Evite conflitos: Ao mesclar ramificações, a mesclagem pode falhar devido a conflitos entre as duas ramificações. Com o rebase, esses conflitos podem ser resolvidos antes do rebase, evitando assim conflitos durante a fusão.

Resumindo, embora o rebase não seja uma solução universal para todas as situações, na maioria dos casos, o uso do rebase pode nos ajudar a criar um histórico de commits mais limpo e intuitivo e melhorar a eficiência da colaboração da equipe.

Dito isto, parece estar falando sobre as vantagens do Rebase, então o Rebase não tem desvantagens? Claro que não, caso contrário, todos teriam mudado de Merge para Rebase há muito tempo. Desvantagens do Rebase:

• Resolver conflitos é trabalhoso. Os conflitos de rebase são comparados por confirmação e os conflitos de mesclagem são comparados com base no resultado final. Se você usar rebase, é melhor mesclar o código com frequência. Caso contrário, se você rebase no fim do desenvolvimento de longo prazo, será realmente um problema. Resolva o conflito até que as pessoas fiquem estúpidas.
• Não há registro de mesclagem, mas o Merge possui um registro; portanto, se houver um problema, ele poderá ser resolvido facilmente.
• As etapas da operação são relativamente incômodas.

5. Conclusão

A questão central do desenvolvimento colaborativo é, na verdade, a fusão.Como mesclar de forma razoável e harmoniosa é um problema que toda equipe precisa considerar. Como os principais comandos do Git, Merge e Rebase, na verdade, têm suas próprias vantagens, e é muito comum usá-los juntos. De acordo com sua própria equipe e situação do projeto, é melhor escolher o método apropriado. Finalmente, desejo-lhe tudo de bom na fusão de código ~