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 Afez umpulldas alterações do repositório remoto para seu repositório local. Então ele fez a mudança do arquivoMyCode.txt, preparou e fez umpushpara o repositório remoto.Enquanto isso o
DEV B, sem saber das alterações doDEV Afez no arquivoMyCode.txt, fez algumas alterações na mesma resgião do arquivo e tentou fazer umpushpara o repositório remoto.O GIT é um sistema de controle de versão, por isso avisou o
DEV Bque ele havia alterado a versão mais antiga do que estava no repo remoto (já que as alterações doDEV Ajá estavam nele)Agora o
DEV Bprecisa primeiro extrair as alterações do repo remoto, atualizar o arquivo e tentar enviar novamente.O
DEV Bfez isso. No entanto, em seu pesadelo mais selvagem, ela recebeu o aviso de que oauto-mergefalhou, 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 Ae remover as dele. - Ele pode remover as mudanças do
DEV Ae ficar com os dele. - Ele pode ficar com as mudanças do
DEV Ae o dele. - Ele pode remover as mudanças do
DEV Ae 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
pullde 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
pullantes de umpushpara 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.
Top comments (1)
Muiito obrigada, esse artigo me ajudou a entender melhor alguns conflitos que tive no estágio!!👏🏻