GIT - Como resolver conflitos de merge
Tags: git, programming, beginners, codequality
Published: 2022-05-14 18:51:45

![Git Merge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ju90mj1tkx425b76rv7u.png) 

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.

![Conflito de Mesclagem](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ir5l6c7vd3xonnrxvnw1.png)

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.