Resolver conflitos de merge no Git visualmente — guia passo a passo

Por que conflitos de merge assustam desenvolvedores (e por que não deveriam)

Se você já usou Git por algum tempo, quase certamente se deparou com o temido conflito de merge. Aquele momento em que o Git diz que não consegue mesclar suas alterações automaticamente pode parecer como bater em uma parede. Muitos desenvolvedores, especialmente os que estão no início da carreira, tratam conflitos de merge como algo que deu errado. Mas a verdade é mais simples: conflitos de merge são uma parte normal do desenvolvimento colaborativo. Eles só precisam da abordagem certa para serem resolvidos de forma eficiente.

O que é um conflito de merge?

Um conflito de merge acontece quando o Git não consegue combinar automaticamente as alterações de dois branches diferentes. Isso normalmente ocorre quando duas pessoas (ou até a mesma pessoa em branches diferentes) editam as mesmas linhas no mesmo arquivo.

Quando o Git detecta um conflito, ele insere marcadores de conflito diretamente nos arquivos afetados:

<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 10000;
>>>>>>> feature/update-timeout

Tudo entre <<<<<<< HEAD e ======= é a sua versão (frequentemente chamada de "ours"). Tudo entre ======= e >>>>>>> é a versão recebida ("theirs"). Seu trabalho é decidir qual deve ser o resultado final, remover os marcadores e informar ao Git que o conflito está resolvido.

O jeito tradicional: editar marcadores de conflito manualmente

A abordagem mais básica é abrir o arquivo com conflito em um editor de texto, encontrar cada conjunto de marcadores de conflito e editar o código manualmente. Para um único conflito em um arquivo pequeno, isso funciona bem. Mas se torna doloroso rapidamente quando você está lidando com:

• Múltiplos conflitos espalhados por um único arquivo
• Vários arquivos com conflito no mesmo merge
• Alterações complexas onde você precisa combinar partes de ambas as versões
• Conflitos aninhados ou adjacentes onde os marcadores são difíceis de ler

Editar marcadores manualmente é propenso a erros. É fácil acidentalmente deixar um marcador para trás, apagar o bloco errado ou introduzir um bug sutil porque você perdeu o controle do que cada versão estava tentando fazer. Tem que haver um jeito melhor.

O jeito visual: usar um editor de merge de 3 vias

O que é merge de 3 vias?

Um merge de 3 vias mostra três versões do arquivo ao mesmo tempo:

• Base -- o ancestral comum, ou seja, a versão do arquivo antes de qualquer um dos branches fazer alterações
• Ours -- a versão do arquivo no seu branch
• Theirs -- a versão do arquivo no branch recebido

Ter as três versões visíveis ao mesmo tempo é transformador. Em vez de ficar olhando para marcadores de conflito e tentando reconstruir o que aconteceu, você pode ver exatamente o que cada lado alterou em relação ao original. Esse contexto torna muito mais fácil decidir como resolver cada conflito.

Como funciona no GitSquid

O GitSquid inclui um editor de merge de 3 vias integrado, projetado para tornar a resolução de conflitos simples, mesmo que você nunca tenha resolvido um conflito antes. Veja como o fluxo de trabalho funciona:

1. Veja todos os arquivos com conflito de uma vez. Quando um merge produz conflitos, o painel de conflitos lista cada arquivo afetado. Você imediatamente sabe o escopo do que precisa ser resolvido.

2. Abra o editor de 3 vias. Clique em qualquer arquivo com conflito para abri-lo no editor de merge. Você verá três colunas lado a lado: Base à esquerda, Ours no centro e Theirs à direita. Cada coluna exibe o conteúdo completo do arquivo com destaque de sintaxe, para que você possa ler o código em contexto.

3. Resolva conflitos bloco por bloco. Cada conflito é destacado e apresentado como um bloco distinto. Para cada conflito, você tem botões de ação claros:

• Use Ours -- manter sua versão do código em conflito
• Use Theirs -- aceitar a versão recebida
• Use Both -- incluir ambas as alterações, uma após a outra

Um clique e o conflito está resolvido. Sem procurar marcadores, sem risco de apagar acidentalmente as linhas erradas.

4. Refinar o resultado. Abaixo das três colunas, um painel de resultado mostra a saída mesclada em um editor de código completo alimentado pelo CodeMirror 6 com destaque de sintaxe. Se nenhuma das opções de um clique produzir exatamente o que você precisa, você pode editar o resultado diretamente. Isso é útil quando você precisa combinar partes de ambas as versões de forma personalizada, como manter a assinatura de uma função de um branch mas a implementação de outro.

5. Marcar como resolvido. Quando estiver satisfeito com o resultado, marque o arquivo como resolvido e passe para o próximo arquivo com conflito. Quando todos os arquivos estiverem resolvidos, você pode completar o merge.

A vantagem principal é que você nunca perde o contexto. Você sempre pode ver como o código era antes de qualquer branch tocá-lo, o que cada branch alterou e qual será o resultado final. Essa clareza elimina a maior parte da ansiedade em torno dos conflitos de merge.

Dicas para evitar conflitos de merge

Mesmo com boas ferramentas, prevenir conflitos é sempre melhor do que resolvê-los. Aqui estão alguns hábitos práticos que ajudam:

• Faça pull com frequência. Quanto mais tempo você passar sem integrar alterações do branch principal, mais seu código diverge do trabalho dos seus colegas. Fazer pull regularmente mantém a diferença pequena e reduz a chance de edições sobrepostas.
• Mantenha branches de curta duração. Um branch de feature que vive por duas semanas acumula muito mais conflitos potenciais do que um que vive por dois dias. Divida funcionalidades grandes em incrementos menores e integráveis.
• Comunique-se com sua equipe. Se duas pessoas precisam trabalhar no mesmo arquivo ou módulo, um aviso rápido pode economizar tempo depois. A coordenação não precisa ser formal; uma mensagem curta geralmente é suficiente.
• Use feature flags. Em vez de manter um branch de longa duração para uma funcionalidade que não está pronta para ser lançada, faça merge por trás de um feature flag. O código é integrado continuamente, mas a funcionalidade fica oculta até estar completa.

Conflitos de merge são normais

Conflitos de merge não são sinal de que algo deu errado. São uma consequência natural de várias pessoas trabalhando na mesma base de código, que é exatamente o que o controle de versão foi projetado para suportar. A diferença entre uma experiência frustrante e uma tranquila geralmente se resume às ferramentas que você usa.

Um editor visual de merge de 3 vias elimina as suposições. Em vez de decifrar marcadores de conflito em um editor de texto, você vê cada versão do código, escolhe a resolução que faz sentido e segue em frente. Com o editor de merge integrado do GitSquid, resolver conflitos se torna apenas mais uma parte do fluxo de trabalho, em vez de algo a temer.