Integrar branches locais com merge

Merge é a integração do histórico de outra branch na branch atual. Não se trata apenas de copiar arquivos: a integração considera os commits que registram as mudanças.

• Destino: branch que receberá a integração. Ela deve estar ativa.
• Origem: branch cujo histórico será integrado ao destino.

Antes de integrar, responda: qual branch precisa receber essas mudanças?

Antes de integrar, localize as branches no histórico com este comando. Ele apenas exibe informações; não altera o repositório.

Além do resumo de --oneline:

• --graph desenha as conexões entre commits, não pastas ou arquivos.
• --all considera todas as referências disponíveis no repositório local do exercício, não apenas a branch atual.
• --decorate exibe os nomes dessas referências junto aos commits.

Neste grafo, siga de cada ponta para baixo:

• O histórico de entrega contém a6c2e81 e 95b1d70.
• O histórico de ajuste-menu contém esses mesmos commits, mais b7d3f90 e c8e4a12.

Assim, a6c2e81 e 95b1d70 são compartilhados. As duas branches apontam para posições diferentes na mesma linha de histórico; ter duas branches não exige duas linhas no desenho.

Neste exemplo, as branches já existem. Você está em ajuste-guia, com o trabalho commitado, e deve integrá-la em entrega.

O destino entrega aponta para um commit anterior da mesma linha: ele é ancestral da ponta da origem e não tem commits exclusivos.

Ative o destino com git switch e informe a origem no git merge.

Neste exemplo, o Git informa:

Fast-forward significa avanço direto. Como entrega já estava na mesma linha de histórico, o Git apenas move sua referência de 3a7f920 até 92b6f03, que já existia na origem.

No grafo abaixo, os três commits são os mesmos de antes. O que mudou foi a posição de entrega, que continua sendo a branch atual.

O commit compartilhado de onde duas linhas de trabalho partiram é o ancestral comum.

Se, depois dele, cada branch ganhou commits que não fazem parte do histórico da outra, os históricos divergiram. Há commits exclusivos tanto no destino quanto na origem.

Considere este grafo ilustrativo. A branch de destino é entrega; a origem é ajuste-contato.

No ancestral comum do exemplo, README.md e contato.md já existiam. Depois dele, ocorreram apenas estas alterações:

Nesse cenário, Git consegue combinar as alterações automaticamente: manter a descrição corrigida e incorporar o novo horário.

Divergência de histórico não significa, por si só, falha na integração automática. Aqui, as mudanças são compatíveis.

Considere um repositório de prática já preparado:

• site é o destino e tem um commit exclusivo que altera README.md.
• menu é a origem e tem um commit exclusivo que altera menu.html.
• Todo o trabalho já está commitado, e as mudanças podem ser combinadas automaticamente.

Execute uma linha por vez. Só prossiga se cada git status indicar ausência de pendências. Após a troca, confirme também que a branch atual é site.

Nesse cenário divergente, o Git combina as mudanças e cria automaticamente um commit de merge. A opção -m fornece a mensagem desse commit no próprio comando, sem depender do editor. A mensagem escolhida deixa claro o que foi integrado e em qual destino.

O commit de merge passa a ser a ponta de site. Neste merge entre duas branches, ele tem dois pais, ou seja, dois commits anteriores aos quais se conecta diretamente:

1. Primeiro pai: a ponta de site antes da integração.
2. Segundo pai: a ponta de menu que foi integrada.

Assim, o novo commit registra a união sem substituir os commits anteriores de nenhuma das duas linhas.

Após a integração bem-sucedida, execute:

Este é um resultado ilustrativo do cenário. Os identificadores serão diferentes no seu repositório.

Neste exemplo, o merge de ajuste-menu em entrega terminou sem conflitos. Permaneça em entrega e abra os arquivos: confira tanto as novidades quanto o conteúdo que deveria permanecer.

git status sem pendências confirma um estado limpo, não a correção do conteúdo. Já git diff vazio indica ausência de diferenças entre os arquivos rastreados no diretório de trabalho e a área de preparação. Ele não compara o projeto antes e depois do merge.

Antes do merge, ajuste-menu apontava para 6a3d920. Consulte o histórico e siga as conexões a partir de entrega: não basta encontrar o nome da origem na saída de --all.

HEAD -> entrega está no commit de merge, conectado às duas linhas anteriores. Assim, o histórico da origem está incorporado ao destino.

ajuste-menu continua em 6a3d920: o merge no destino não move nem exclui a branch de origem. No avanço direto, os dois nomes podem ficar no mesmo commit porque o destino avança até a origem.

A versão que será revisada está na branch revisao. Ela deve receber as mudanças de prazo-entrega.

Neste caso simulado, todo o trabalho já está commitado e não há pendências. Desde a base comum:

• revisao alterou apenas README.md, incluindo Canal de suporte: e-mail.
• prazo-entrega alterou apenas entrega.txt, incluindo Prazo: 5 dias úteis.

Os dois arquivos já existiam. Seus demais conteúdos devem ser preservados.

Saída ilustrativa de git log --oneline --graph --all --decorate: