Quando o Git não consegue combinar duas ramificações automaticamente, ele pausa e deixa as alterações conflitantes para você reconciliar. No Mac, use git status para encontrar os arquivos afetados, compare ambas as versões, edite cada conflito em um resultado combinado deliberado e, em seguida, prepare (stage) e conclua o merge. A chave é preservar a intenção de ambas as alterações, não aceitar cegamente um dos lados ou presumir que manter ambos os blocos produzirá um código funcional.

Confirme a operação e proteja edições não finalizadas

Abra o Terminal ou o terminal integrado do seu editor, navegue até o repositório e verifique seu estado:

cd "/path/to/repository"
git status

Use o caminho real da pasta no lugar do exemplo. O status do Git informa quais arquivos não foram mesclados e se a operação é um merge, rebase ou outra ação. Este artigo aborda o merge. Para um merge comum, o Git mantém a ramificação atual inalterada enquanto aguarda que você resolva os conflitos; os caminhos mesclados sem problemas já estão atualizados, enquanto os caminhos conflitantes precisam de revisão. Documentação do git merge do Git

Se você tiver trabalho não commitado de antes do merge, tome cuidado para não sobrescrevê-lo durante a edição. O Git documenta git merge --abort como uma forma de interromper um merge, mas observa que isso pode nem sempre reconstruir alterações não commitadas pré-existentes. Se o estado não estiver claro, salve uma cópia separada de edições locais importantes antes de continuar. Aborte apenas quando pretender interromper o merge e inspecione o status resultante depois. Instruções de conflito de merge do Git

Leia cada conflito como duas propostas

Abra cada arquivo listado em um editor de texto. Um conflito de texto é comumente marcado desta forma:

<<<<<<< HEAD
current branch version
=======
incoming branch version
>>>>>>> branch-name

O texto acima de ======= é geralmente a versão da ramificação atual; o texto abaixo é geralmente o da ramificação que está sendo mesclada. Os rótulos podem variar. O Git registra o ancestral comum e as versões de ambas as ramificações no índice, e o arquivo de trabalho mostra um resultado com marcadores de conflito para você editar. Documentação de merge do Git

Trate as duas seções como evidências das alterações pretendidas, não como opções que você deve aceitar por inteiro. Pergunte a si mesmo o que cada edição estava tentando alcançar. Um lado pode adicionar uma condição de validação enquanto o outro altera o nome de um campo; preservar ambos pode significar combiná-los em uma única condição atualizada. Para um conflito no nível do arquivo, como um lado excluindo um arquivo enquanto o outro o edita, decida se o arquivo deve permanecer e, em caso afirmativo, incorpore as edições necessárias. Se a intenção não estiver clara a partir das linhas, inspecione o código ao redor ou pergunte ao autor da alteração antes de decidir.

Remova todos os marcadores de conflito e escreva uma versão final coerente. Não deixe simplesmente ambos os blocos em sequência, a menos que seja isso que o programa ou documento deva conter. Manter ambos pode duplicar declarações, sobrescrever comportamentos ou criar sintaxe inválida. Por outro lado, escolher apenas um bloco pode descartar o trabalho útil da outra ramificação. A resolução correta depende do arquivo ao redor e do propósito de cada alteração.

Revise e prepare (stage) os arquivos resolvidos

Salve o arquivo editado e inspecione as alterações. Para um arquivo conflitante, git diff mostra o trabalho de resolução de conflitos ainda presente em sua árvore de trabalho. Verifique todo o contexto ao redor, não apenas as linhas marcadas. Procure por marcadores restantes com a função de busca do seu editor ou use este comando no repositório:

git grep -n -E '^(<<<<<<<|=======|>>>>>>>)'

Se encontrar correspondências, revise-as: documentações legítimas ou fixtures de teste podem conter essas strings, portanto, não exclua correspondências indiscriminadamente. Quando o resultado de um arquivo estiver correto, prepare-o passando seu caminho entre aspas para git add, por exemplo git add "Sources/Example.swift". A preparação (staging) informa ao Git que o conflito do arquivo foi resolvido; isso não comprova que o resultado esteja correto. As instruções do Git são editar cada conflito, adicionar os caminhos resolvidos e, em seguida, fazer o commit ou continuar o merge. Documentação de merge do Git

Para um fluxo de trabalho visual no Mac, o Visual Studio Code lista os arquivos com conflito em Alterações de Mesclagem (Merge Changes) no Controle do Código-Fonte. Abra um arquivo e use suas ações de conflito em linha ou Abrir no Editor de Mesclagem (Open in Merge Editor) para inspecionar o lado atual, o lado de entrada e o resultado. A ação Aceitar Ambas as Alterações (Accept Both Changes) do editor mantém ambas as seções em sequência; revise o arquivo resultante e combine ou ajuste o conteúdo quando necessário. Salve o resultado e prepare o arquivo no Controle do Código-Fonte. Esses controles pertencem ao VS Code; outros editores podem usar rótulos ou recursos diferentes. Guia de conflitos de merge do VS Code

Conclua o merge e verifique o resultado

Depois de resolver e preparar cada arquivo com conflito, verifique o estado novamente:

git status
git diff --cached

Revise o diff preparado para garantir que ambas as contribuições pretendidas apareçam de forma lógica no resultado final e que edições não relacionadas não tenham sido incluídas. Execute as verificações relevantes do projeto, se disponíveis; o Git não consegue determinar se a lógica combinada se comporta como esperado.

Para um merge via linha de comando, conclua a operação com git merge --continue (ou faça o commit do merge quando o Git orientar a fazê-lo). O comando --continue do Git verifica se há um merge em andamento antes de criar o commit. Em seguida, execute git status novamente para confirmar que o merge não está mais em andamento. Se o Git relatar mais conflitos, resolva e prepare esses arquivos também. Instruções de merge do Git

Um conflito é resolvido com segurança quando o arquivo final contempla deliberadamente o trabalho pretendido de ambas as ramificações, o diff preparado corresponde a esse resultado e o merge é concluído. Quando você não conseguir determinar o que um dos lados pretendia realizar, pause e obtenha esse contexto antes de descartá-lo ou reescrevê-lo.

Fontes