GIT - Como resolver conflitos de merge

GIT é um sistema de controle de versão distribuída de código aberto. Ele nos ajuda a gerenciar arquivos de projeto facilmente usando ramificações locais, staging e fluxos de trabalho. Muitos desenvolvedores usam o Git hoje, e eles geralmente estão mais familiarizados com conceitos básicos de GIT como:

• Como iniciar um repositório.
• Como criar Branches
• Como aplicar/desfazer mudanças.
• Como criar commits de mudanças.

Entre outras coisas....

No entanto, muitos desenvolvedores ficam confusos sobre conceitos e como resolver conflitos de merge. Para isso venho falar nesse artigo como iremos resolver conflitos de fusão de forma prática.

O que é Git Merge e O que são Conflitos de Fusão?

GIT é um sistema de controle de versão que mantém um histórico de todas as suas versões de arquivo. Você pode voltar para qualquer uma das versões a qualquer momento e recuperar uma versão mais antiga.

Suponha que você tenha criado um arquivo chamado MyCode.txt e enviado para um repositório GIT (GitHub, GitLab ou BitBucket). Neste ponto, o arquivo tem sua versão atual associada a ele. Agora, se o seu colega de trabalho alterou o mesmo arquivo e o empurrou de volta para o repositório, o arquivo tem uma nova versão associada.

GIT Merge é um recurso que permite manter o conteúdo atual do arquivo em sincronia com outras versões anteriores. Isso é essencial porque qualquer pessoa em qualquer momento deve estar trabalhando no conteúdo mais recente do arquivo sem substituir quaisquer alterações das versões anteriores. Ou seja o GIT merge ajuda você a mesclar mudanças de outros desenvolvedores antes de empurrar uma nova mudança para o mesmo arquivo

No caso do GIT Merge, precisamos estar cientes de duas coisas:

1º) Alterações: Que tipo de operações ocorreram entre duas versões de um arquivo? Novos conteúdos são adicionados ou removidos ou o conteúdo existente é atualizado.

2º) Possibilidades: Existem duas possibilidades... As alterações aconteceram no arquivo em regiões diferentes ou as alterações aconteceram no arquivo na mesma região. A mesma região significa que os desenvolvedores fizeram alterações em torno do mesmo lugar (por exemplo, parágrafos, linhas e assim por diante) de um arquivo.

Felizmente, o GIT cuida automaticamente da maioria desses casos usando a estratégia de auto-merge. Mas quando as alterações ocorreram no arquivo na mesma região, o GIT não realizará uma fusão automática. Em vez disso, deixa para você resolver os conflitos de merge.

GIT Merge Conflics: Uma História de Terror

Vamos entender as situações acima com uma história de dois desenvolvedores, DEV A e o DEV B

• DEV A fez um pull das alterações do repositório remoto para seu repositório local. Então ele fez a mudança do arquivo MyCode.txt, preparou e fez um push para o repositório remoto.

• Enquanto isso o DEV B, sem saber das alterações do DEV A fez no arquivo MyCode.txt, fez algumas alterações na mesma resgião do arquivo e tentou fazer um push para o repositório remoto.

• O GIT é um sistema de controle de versão, por isso avisou o DEV B que ele havia alterado a versão mais antiga do que estava no repo remoto (já que as alterações do DEV A já estavam nele)

• Agora o DEV B precisa primeiro extrair as alterações do repo remoto, atualizar o arquivo e tentar enviar novamente.

• O DEV B fez isso. No entanto, em seu pesadelo mais selvagem, ela recebeu o aviso de que o auto-merge falhou, e então ele precisa agora resolver os conflitos de merge.

Essa história parece familiar? Aconteceu com você? Há uma chance de você ter estado no lugar do DEV B no passado. Se não, você vai chegar lá eventualmente fique tranquilo.... Então vamos entender como o DEV B tem que lidar com essa situação de forma eficiente.

Como resolver conflitos de mesclagem no GIT

Resolver conflitos de fusão não é tão complicado quanto parece. Em 90% dos casos, é mais fácil uma vez que você tem uma compreensão clara das mudanças e uma mente pacífica.

Processo de pensamento

Uma vez que DEV B faz um push das mudanças, o arquivo local do DEV B tem suas mudanças mais as mudanças do DEV A. Agora o DEV B pode fazer uma dessas quatro coisas:

• Ele pode ficar com as mudanças do DEV A e remover as dele.
• Ele pode remover as mudanças do DEV A e ficar com os dele.
• Ele pode ficar com as mudanças do DEV A e o dele.
• Ele pode remover as mudanças do DEV A e das suas mudanças.

Tudo bem, mas qual ele deveria estar fazendo? Isso depende inteiramente das necessidades do projeto e dos casos de uso. O DEV B entenderá as mudanças que estão por vir e fará o que for relevante para a situação

Então, o que são mudanças que estão por vir? Como o DEV B vai identificar isso? Como o DEV B faz as mudanças? Eu sei que você tem muitas perguntas. Vamos obter as respostas para todos eles, tomando um par de exemplos da vida real na seção abaixo.

Etapas para resolver conflitos de fusão no GIT

Vamos pegar alguns exemplos reais de conflitos de fusão, e aprender a resolvê-los.

Exemplo 1: As alterações estão na mesma região do arquivo

Quando o GIT não pode realizar um auto-merge porque as alterações estão na mesma região, indica as regiões conflitantes com caracteres especiais. As sequências de caracteres são assim:

<<<<<<<

=======

>>>>>>>

Tudo entre <<<<<<< e ======= são suas mudanças locais. Essas alterações ainda não estão no repositório remoto. Todas as linhas entre ======= e >>>>>>> são as alterações do repositório remoto ou de outro ramo. Agora você precisa olhar para essas duas seções e tomar uma decisão.

A imagem abaixo mostra o conteúdo de um arquivo indicando que a fusão automática não ocorreu e há um conflito. O conflito está na linha onde modificamos o arquivo localmente adicionando uma linha - Sleep. Mas, enquanto isso, outra pessoa fez uma mudança adicionando a linha - Gym na mesma região.

Assim, a linha é marcada como a mudança local e à medida que a entrada muda do repositório remoto ou de outro ramo.

Com base nas necessidades do seu caso de uso e projeto, você fará a chamada para resolver o conflito. Se você precisar manter apenas a linha com - Sleep, você vai manter isso e remover o resto dos textos conflitantes. Nesse caso, o conteúdo do arquivo torna-se:

- Eat
- Read
- Sleep

Pelo contrário, você pode manter a linha - Gym e remover as - Sleep alterações:

- Eat
- Read
- Gym

Se você precisar manter ambas as linhas, remova as linhas relacionadas aos indicadores de conflito:

- Eat
- Read
- Sleep
- Gym

Se você acha que nenhuma das mudanças são necessárias, remova todas elas.

- Eat
- Read

Cabe inteiramente a você decidir quais mudanças são relevantes para a situação. Após as alterações, você precisa ter certeza de que nenhum dos caracteres que indicam conflitos existem (<<<<<<<, ============= >>>>>>>) no arquivo. Uma vez que você resolver com as mudanças, faça o seguinte:

Faça as mudanças:

git add <files>

Confirme as alterações com uma mensagem:

git commit -m "Message"

Por fim, envie as alterações para o repositório remoto:

git push

Isso é tudo o que há para resolver do conflito de mesclagem neste cenário.

Exemplo 2: O arquivo é removido na branch remota/outra

Em conflitos de mesclagem de arquivos removidos, um DEV exclui um arquivo em uma branch enquanto outro DEV edita o mesmo arquivo em outra branch. Neste caso, você precisa decidir se quer manter o arquivo ou se ele estava certo em excluí-lo. Para adicionar o arquivo excluído de volta a sua branch, faça isso:

git add <file-name>

Para prosseguir com a exclusão do arquivo, faça isso:

git rm <file-name>

Em seguida, comprometa suas alterações com uma mensagem:

git commit -m "Message"

Finalmente, faça um push:

git push

O que vem depois?

Se você aprender com os dois exemplos acima e praticá-los, você será capaz de cuidar da maioria dos cenários e resolver seus conflitos de fusão. Então, a prática leva a perfeição!

Algumas dicas importantes para você:

• Todos os exemplos mostrados neste artigo assumem que você está usando o GitBash ou qualquer outro Git CLI para resolver conflitos de fusão. Você pode usar qualquer outra ferramenta de GUI para fazer o mesmo.

• Sempre realize pull de suas branchs remotas/outros relacionados antes de iniciar qualquer novo trabalho lógico em seu código. Manterá sua branch atualizada o máximo possível e reduzirá as chances de conflitos.

• Sempre realize o pull antes de um push para ter certeza de que você não enfrentará quaisquer rejeições de GIT.

• Converse com seus pares/co-desenvolvedores quando você não puder fazer uma chamada sobre o que manter versus o que remover. Junte-se para resolver conflitos difíceis de merge.