Introdução ao Git Merge e Git Rebase: Por que e quando usá-los

Freqüentemente, os desenvolvedores podem escolher entre Mesclar (mesclar) e Rebase (relocação). No Google, você verá uma opinião diferente; muitos são aconselhados a não usar o Rebase, pois isso pode causar problemas sérios. No artigo, explicarei o que são mesclagem e movimentação, por que você deve (ou não deve) usá-las e como fazê-lo.



Git Merge e Git Rebase compartilham o mesmo objetivo. Eles são projetados para integrar alterações de uma ramificação para outra. Embora o objetivo final seja o mesmo, os princípios de operação são diferentes.

Algumas pessoas pensam que você deve sempre usar Rebase, outras preferem Merge. Isso tem seus prós e contras.

Git merge

A mesclagem é uma prática comum para desenvolvedores que usam sistemas de controle de versão. Independentemente de as ramificações serem criadas para teste, correção de bugs ou por outros motivos, a mesclagem captura as alterações em outro local. A mesclagem pega o conteúdo da ramificação de origem e os mescla com a ramificação de destino. Nesse processo, apenas a ramificação de destino é alterada. O histórico das ramificações de origem permanece inalterado.

Prós:

• simplicidade;
• preserva a história completa e a ordem cronológica;
• mantém um contexto de ramificação.

Contras:

• o histórico de confirmações pode ser preenchido (poluído) com muitas confirmações;
• a depuração usando o git bisect pode ficar mais complicada.

Como fazer

Mesclar a ramificação principal na ramificação de recursos usando os comandos checkout e mesclar .

$ git checkout feature $ git merge master (or) $ git merge master feature 

Isso criará um novo "Merge commit" no ramo de recurso, que contém um histórico dos dois ramos.

Git rebase

Rebase é outra maneira de enviar alterações de um ramo para outro. Rebase compacta todas as alterações em um único patch. Em seguida, integra o patch no ramo de destino.

Ao contrário da mesclagem, a movimentação substitui o histórico porque transfere o trabalho concluído de uma ramificação para outra. O processo elimina a história indesejada.



Prós:

• Simplifica uma história potencialmente complexa
• Simplificação de manipulações com um único commit
• Evitando fusões consolidadas em repositórios e ramificações ocupadas
• Limpa confirmações intermediárias, transformando-as em uma única confirmação, o que é útil para comandos do DevOps

Contras:

• A compactação de recursos para algumas confirmações pode ocultar o contexto
• Mover repositórios públicos pode ser perigoso ao trabalhar em equipe
• Mais trabalho aparece
• Para recuperação com ramificações excluídas, é necessário um push. Isso leva a uma atualização de todos os ramos com o mesmo nome, local e remotamente, e isso é terrível.

Se você fizer a jogada incorretamente, a história mudará, e isso pode levar a sérios problemas, portanto, faça isso!

Como fazer

Mova o ramo do recurso para o ramo principal usando os seguintes comandos.

 $ git checkout feature $ git rebase master 

Isso move toda a ramificação da função para a ramificação principal. O histórico do projeto está mudando, novas confirmações são criadas para cada confirmação na ramificação principal.

Movimento interativo

Isso permite alterar as confirmações quando elas são movidas para uma nova ramificação. Isso é melhor do que a movimentação automática, pois fornece controle total sobre o histórico de confirmações. Normalmente usado para limpar o histórico antes de mesclar a ramificação do recurso no mestre.

 $ git checkout feature $ git rebase -i master 

Isso abrirá o editor, listando todos os commits que serão movidos.

 pick 22d6d7c Commit message#1 pick 44e8a9b Commit message#2 pick 79f1d2h Commit message#3 

Isso determina exatamente como será a ramificação após a movimentação. Organizando objetos, você pode fazer a história como quiser. Você pode usar os comandos de correção , squash , edição e assim por diante.

Qual usar?

Então, o que é melhor? O que os especialistas recomendam?

É difícil tomar a única decisão certa sobre qual é melhor usar, pois todas as equipes são diferentes. Tudo depende das necessidades e tradições da equipe.

Tome decisões com base na competência da equipe no Git. A simplicidade ou a reescrita do histórico são importantes para você, ou talvez algo mais?

O que eu recomendo?

À medida que a equipe cresce, fica difícil gerenciar ou acompanhar as mudanças no desenvolvimento usando uma fusão. Para ter um histórico de consolidação limpo e compreensível, é aconselhável usar Rebase.

Benefícios do Rebase:

• Você desenvolve localmente: se você não compartilhou seu trabalho com mais ninguém. Por enquanto, você deve preferir mudar a fusão para manter sua história em ordem. Se você tiver uma bifurcação de repositório pessoal que não seja compartilhada com outros desenvolvedores, poderá fazer uma nova recuperação mesmo depois de mudar para sua filial.
• Seu código está pronto para revisão: você criou uma solicitação de recebimento. Outros analisam seu trabalho e, potencialmente, o ligam para uma revisão local. No momento, você não deve mudar seu trabalho. Você deve criar uma confirmação "refazer" e atualizar a ramificação. Isso ajuda a acompanhar as solicitações de recebimento e evita a quebra acidental da história.
• A revisão está pronta e pronta para integração no ramo de destino. Parabéns! Você está prestes a excluir sua ramificação de recursos. Dado que a partir de agora, outros desenvolvedores não buscarão essas alterações, essa é sua chance de mudar sua história. Nesse ponto, você pode reescrever o histórico e redefinir as confirmações originais, e essas irritantes “alterações” e “mesclagens” se fundem em um pequeno conjunto de confirmações direcionadas. Criar uma mesclagem explícita para essas confirmações é opcional, mas é importante. Registra quando a função atingiu o mestre.

Agora você sabe, embora insignificante, mas a diferença entre Mesclar e Rebase. Estou certo de que você tomará a decisão certa e usará o que é certo para você.

Não esqueça:

 code = coffee + developer