Cá está você, uma pessoa iniciando em sua carreira de programação, e finalmente você tem a chance de trabalhar em um projeto colaborativo. Você vai tode feliz e com orgulho, dar merge na primeira issue em que você trabalhou. Mas ELE aparece. Sim, o temido Conflito de merge!
A primeira vez que eu me deparei com isso (e a segunda, e também na terceira e talvez na décima) eu confesso que dei uma surtadinha.
Hoje eu sei resolver esses conflitos (quase sempre) e vim ensinar pra vocês algumas maneiras de fazer isso.
Nota: As dicas abaixo são apenas para Conflitos de Merge, para conflitos da sua vida pessoal, por favor procure uma pessoal profissional em psicologia.
Quando o conflito acontece…
Respire fundo!
Eu sei, quando isso aparece pelas primeiras vezes, dá aquela sensação de que a gente fez algo de errado né?
E dá um super medo de fazer alguma besteira e apagar código alheio, mas respira. A gente vai resolver isso aqui.
O que aconteceu?
Antes de resolver os conflitos, é uma boa ideia tentar entender o porquê dele ter ocorrido.
Não, você não fez algo de errado (eu acho).
Sistemas de controle de versionamento, como o Git, são ferramentas super legais que te ajudam a saber o que aconteceu no seu código, mudanças que foram feitas, quem fez o quê.
Mas não é mágica, e às vezes ele precisa de uma ajudinha.
No geral, conflitos de merge acontecem quando duas ou mais pessoas fazem modificações que confundem o git, e ele não sabe qual das 2 opções aplicar, como quando alguém deleta um arquivo ou uma linha, mas outra pessoa que ainda não tem o código atualizado vai lá e edita o arquivo ou linha deletada.
No exemplo que eu estou usando, o problema é que duas pessoas (eu e meu alter ego) fizemos modificações diferentes na mesma linha do arquivo.
Vamos ajudar o git!
O que causa um conflito de merge é quando o git fica confuso como nos exemplos que mencionei acima, e nossa missão aqui é ajudar o git!
Hoje eu vou explicar como fazer isso dentro do Github, mas resolver conflitos dentro do VS Code é bem parecido.
No Github, quando o conflito acontece, nós vemos isso aqui:
Vamos começar clicando no botão no canto direito: Resolve conflicts.
Entendendo o conflito
Isso vai nos levar para o nosso arquivo conflituoso, vamos estudá lo:
O Github é um fofo que nos mostra, em vermelho, onde está o conflito. Ele nos indica onde ele começa e onde acaba. O código conflitante começa depois do <<<<<<< main e termina antes do próximo <<<<<<< main.
Como mencionei, o motivo do conflito aqui é que duas pessoas fizeram mudanças diferentes na mesma linha.
No caso, a mudança da pessoa 1 está na linha 8, acima do ======= e a mudança da pessoa 2 está na linha 10, abaixo do =======
Resolvendo o conflito
Primeiramente temos que decidir qual das duas opções está correta. Nesse caso, eu quero que as duas mudanças sejam mantidas, as duas estão corretas, o único problema foi de estarem na mesma linha.
Para resolver esse conflito, mudamos o código entre os <<<<<<< main e deixamos ele da maneira esperada, removendo o =======
Conferimos se é isso mesmo e se estiver certinho, removemos os dois <<<<<<< main
Agora lá no canto superior direito, clicamos em Mark as resolved e comitamos o merge.
O Github vai te avisar que esse commit vai para main, tem certeza que ta ok?
Eu entendo, pode updatear a main Github!
E ta dã, podemos fazer nossa Pull Request! Parabéns!
Conclusão
E ai, bora resolver aquele conflito de merge que faz uma semana que tá lá mas você finge que não existe? Haha
O exemplo que eu dei foi de um conflito mais simples, mas é a base para resolver conflitos maiores, então espero que te ajude!
Top comments (3)
Uma coisa que ajuda muito a reduzir os conflitos é um formatador de código, isso evita que duas pessoas escrevam o mesmo código de formas diferentes, por exemplo, um coloca espaço (
a + b), outro não (a+b), indentação diferente, espaços em branco no final da linha... tudo isso podem gerar conflitos, e uma ferramenta padronizando o código ajuda a evitar esses conflitos "desnecessários". E a vantagem do conflito no merge (se é que pode chamar de vantagem) é que ele conflita tudo de uma vez, operações como rebase também podem dar conflito, e nesse caso cada commit feito pode dar um conflito diferente, ou seja, pode ser necessários resolver uma quantidade de conflitos igual ao número de commits, e um de cada vez, até chegar no último e terminar a operação, porém sempre visando a modificação de cada commit, e não do código final desejado, por isso manter um histórico com poucos commits, e preferencialmente não fazendo e desfazendo alterações pode ser preferível.Já sei onde vir no próximo conflito😆. Ótimo artigo 👏🙋♂️
Some comments may only be visible to logged-in visitors. Sign in to view all comments.