Resolver conflitos simples de merge

Considere um repositório já preparado: as branches main e ajuste-horario têm mudanças diferentes na mesma linha do arquivo fictício aviso.txt, todas já commitadas. Antes do merge, não havia alterações pendentes. Na branch atual, main, foi executado o comando abaixo.

O conflito ocorre porque o Git não consegue combinar automaticamente mudanças incompatíveis no mesmo trecho. A mensagem indica que a integração não foi concluída: há uma divergência que exige resolução manual.

Consulte git status na pasta do repositório. Neste cenário, a seção Caminhos não mesclados identifica os arquivos cuja resolução ainda está pendente.

• No ramo main: identifica a branch atual.
• Caminhos não mesclados: aponta pendências de resolução neste merge.
• ambos modificados: aviso.txt: as duas branches alteraram esse arquivo e o Git não conseguiu combinar todas as mudanças. O caminho a examinar é aviso.txt.

Neste exemplo, o merge de ajuste-horario foi iniciado na branch main. Veja como ficou o arquivo fictício aviso.txt. Por enquanto, apenas identifique as duas versões, sem editar.

• <<<<<<< HEAD inicia o bloco. O trecho até ======= vem da branch atual, main, que recebe a integração.
• ======= separa as duas versões.
• O trecho entre ======= e >>>>>>> ajuste-horario vem da branch integrada, ajuste-horario. O último marcador encerra o bloco e identifica essa branch.

Os marcadores mostram de onde vem cada versão, não qual está correta. O trecho de HEAD não tem prioridade por aparecer primeiro, e o trecho da branch integrada não tem prioridade por vir depois.

Resolver o conflito não é escolher automaticamente a branch atual ou a integrada. O conteúdo final deve atender à intenção da mudança.

Você pode:

• Escolher uma versão, quando ela já contém o resultado desejado.
• Combinar informações compatíveis das duas versões.
• Reescrever o trecho, quando nenhuma versão expressa bem o resultado esperado.

Neste exemplo fictício, o pedido para aviso.txt é claro: o encontro começa às 10h e a entrada é gratuita. Nenhuma das versões abaixo atende sozinha ao pedido completo.

A oficina deve começar às 16h, e os participantes precisam trazer lápis e papel. Mantenha o título e o local sem alterações.

Depois de editar, confira:

• Os sinais do conflito: todos os blocos foram tratados e seus marcadores removidos?
• O conteúdo: o arquivo inteiro corresponde ao resultado esperado?

Um arquivo pode estar sem nenhum marcador e ainda trazer uma informação errada ou incompleta.

Leia o arquivo do início ao fim procurando:

• Perdas: alguma informação que deveria permanecer foi apagada, inclusive fora dos blocos?
• Duplicações: uma linha ficou repetida sem necessidade ao combinar as versões?
• Contradições: há informações incompatíveis entre si ou diferentes do que foi solicitado?

Neste exemplo fictício, o aviso deve informar atendimento de segunda a sexta, das 9h às 18h, e fechamento aos sábados. O título “Atendimento” e a linha “Canal: formulário do site”, que não estavam em conflito, devem permanecer.

Veja o arquivo completo após uma tentativa de resolução:

O arquivo já foi corrigido, conferido e salvo, mas o Git ainda pode listá-lo como não mesclado. Use git add para sinalizar que você resolveu o conflito.

Nos exemplos, aviso.txt representa o arquivo corrigido. Use o caminho real do seu arquivo.

Confirme no git status que não restam caminhos não mesclados. Quando todos os conflitos foram sinalizados como resolvidos, o Git informa que o merge ainda está em andamento. Resolver os conflitos não conclui a integração.

Use git diff --staged para conferir as alterações preparadas para o commit de merge. Revise também as mudanças integradas automaticamente pelo Git, não apenas o arquivo que teve conflito.

Confira se o conjunto das alterações corresponde ao resultado esperado.

Todos os conflitos foram resolvidos e as alterações preparadas já foram conferidas. Agora, conclua o merge que ainda está em andamento:

Nesse contexto, o comando cria o commit de merge e encerra a integração em andamento. Ele registra a resolução manual junto às demais alterações do merge, inclusive as combinadas automaticamente pelo Git.

Depois que o commit for criado, consulte o estado do repositório e o histórico:

• Estado: no cenário de prática, o git status deve indicar uma área de trabalho limpa, sem alterações pendentes nem aviso de merge em andamento.
• Histórico: localize o novo commit de merge, com a mensagem escolhida, unindo as duas linhas de histórico. A branch atual e HEAD devem apontar para ele.

No Windows, abra o Git Bash; no macOS ou Linux, use um terminal com Bash. Cole o bloco inteiro abaixo.

Ele cria uma pasta temporária nova, configura uma identidade fictícia apenas nesse repositório e prepara o conflito. Não altera seus projetos existentes. É uma preparação auxiliar, não um roteiro de resolução — você não precisa memorizar o bloco.

A mensagem de conflito no final é esperada. Depois, execute o comando cd que o bloco exibir para entrar na pasta do desafio. Se ocorrer outro erro, não prossiga com a prática.

Na pasta criada, a branch atual é main. A integração de ajustar-local já foi iniciada e parou em um conflito no arquivo encontro.txt.

As alterações das duas branches estavam commitadas e não havia alterações pendentes antes do merge. Continue esse merge; não inicie outro.

O encontro deve acontecer às 15h, na sala Verde. Mantenha o título do arquivo e a orientação de levar um caderno.

Seu objetivo é concluir a integração com esse conteúdo, sem marcadores de conflito nem alterações pendentes, e identificar o commit de merge que a registrou.

Guarde as saídas do terminal durante a execução: sua entrega deve mostrar o que aconteceu de verdade, não apenas listar os comandos que você usaria.