Merge — o que é, como funciona merge e estratégias de fusão

O que é merge no Git

Merge é o comando git merge que combina as alterações da branch especificada na branch atual. O Git encontra o ancestral comum (commit base), calcula o diff de cada branch em relação ao ancestral e cria um commit de merge contendo o conjunto combinado de alterações. O resultado é que a branch de destino recebe todas as alterações da branch mesclada.

Sintaxe: enquanto estiver na branch de destino (ex.: main), execute git merge feature. O Git cria automaticamente um commit de merge se não houver conflitos. A mensagem padrão do commit de merge é: “Merge branch 'feature' into main”. Você pode alterar a mensagem usando a flag -m ou editá-la no editor aberto.

O merge é uma operação não destrutiva. Ao contrário do rebase, o merge não altera commits existentes: eles mantêm os mesmos hashes, autores e datas. Isso torna o merge a única maneira segura de mesclar branches nas quais vários desenvolvedores trabalham simultaneamente. Se algo der errado, o merge pode ser cancelado com git merge --abort.

# Trocar para a branch de destino
git checkout main

# Mesclar branch de feature
git merge feature

# Resultado — commit de merge com dois pais
git log --oneline --graph

# Merge com mensagem personalizada
git merge feature -m "feat: integrate authentication module"

Tipos de merge: regular, squash, fast-forward

O Git oferece três modos de merge que são escolhidos com base no resultado desejado. O merge regular (padrão) cria um commit de merge. O squash merge combina todos os commits da branch de feature em um só. Fast-forward move o ponteiro da branch sem criar um commit, se possível. A escolha do modo depende do fluxo de trabalho da equipe e das regras de histórico.

Merge regular (--no-ff) — cria um commit de merge mesmo que o merge pudesse ser feito como fast-forward. Recomendado para a branch main: um commit de merge marca claramente o ponto de integração da feature e permite reverter todas as alterações da branch de feature com um único revert do commit de merge. O GitHub usa este modo por padrão ao mesclar PRs com o botão Merge.

Squash merge (--squash) — agrupa todos os commits da branch de feature em um único commit na branch de destino. Útil quando o histórico preliminar da branch de feature não deve poluir o main. Desvantagem: perde-se o vínculo com os commits originais — não é possível ver como a feature foi desenvolvida passo a passo. O GitHub usa este modo ao selecionar “Squash and merge” em um PR.

Fast-forward (--ff) — se a branch de destino não tiver novos commits desde que a branch de feature divergiu, o Git simplesmente move o ponteiro para frente sem criar um commit de merge. O histórico permanece linear. A flag --no-ff força um commit de merge, enquanto --ff-only resultará em erro se fast-forward não for possível.

# Forçar commit de merge (recomendado para main)
git merge --no-ff feature

# Squash merge — todos os commits em um
git merge --squash feature
git commit -m "feat: add authentication"

# Fast-forward apenas se possível
git merge --ff-only feature

# Abortar merge conflituoso
git merge --abort

Estratégias de merge do Git

As estratégias de merge determinam o algoritmo que o Git usa para combinar alterações. Cada estratégia é adequada para diferentes cenários. O Git seleciona automaticamente a estratégia apropriada, mas os desenvolvedores podem especificá-la explicitamente com a flag --strategy. Compreender as estratégias ajuda a prever o comportamento do Git em merges complexos.

Recursive — a estratégia padrão para mesclar duas branches. O Git encontra o ancestral comum, calcula as alterações em cada branch e as mescla. Se um ancestral comum for encontrado, o recursive lida corretamente com renomeações e adições de arquivos. Durante conflitos, o recursive pode usar opções adicionais: ours (escolher automaticamente nossa versão) e theirs (escolher a versão deles).

Octopus — para mesclar mais de duas branches simultaneamente: git merge feature1 feature2 feature3. O Octopus não suporta resolução de conflitos — todos os conflitos devem ser resolvidos antes de invocar o comando. É raramente usado, principalmente para mesclar várias branches independentes que garantidamente não entram em conflito (ex.: módulos diferentes).

Ours — uma estratégia especial que ignora completamente as alterações da branch mesclada e mantém o conteúdo atual da branch de destino. Um commit de merge é criado, mas o conteúdo permanece inalterado. Útil quando você precisa registrar no histórico o fato da fusão, mas na prática rejeitar todas as alterações da outra branch.

Resolução de conflitos de merge

O conflito de merge ocorre quando as mesmas linhas de um arquivo foram alteradas de forma diferente em ambas as branches. O Git não consegue determinar automaticamente qual versão está correta e pausa o merge. Um conflito também pode surgir quando um arquivo é renomeado em uma branch e modificado em outra, ou quando o mesmo arquivo é simultaneamente excluído e modificado.

Processo de resolução: o Git marca os arquivos em conflito com marcadores. O arquivo mostra seções com <<<<<<< HEAD (nossa versão), ======= (separador) e >>>>>>> feature (versão deles). O desenvolvedor edita manualmente a seção conflitante, seleciona as linhas desejadas de ambas as versões, remove os marcadores, salva o arquivo e o adiciona ao índice com git add.

Para resolução visual de conflitos, o Git oferece mergetool — uma ferramenta externa de comparação. Ferramentas mergetool populares: Meld, KDiff3, Beyond Compare, VS Code (editor de conflitos integrado). O Mergetool exibe três painéis: nossa versão, versão deles e o resultado. O desenvolvedor seleciona visualmente os blocos de código para incluir no arquivo final.

# Iniciar merge e detectar conflito
git merge feature
# CONFLITO (conteúdo): Conflito de merge em src/main.swift

# Verificar arquivos em conflito
git status

# Abrir mergetool visual
git mergetool

# Após resolução — add e commit
git add src/main.swift
git commit

# Abortar merge
git merge --abort

Quando escolher merge em vez de rebase

Merge é preferível ao rebase em várias situações-chave. Primeira: ao trabalhar com branches públicas acessíveis a outros desenvolvedores. O merge não reescreve o histórico, então os colegas podem sincronizar com segurança. Fazer rebase em uma branch pública cria um histórico divergente e causa conflitos para todos que já possuem os commits antigos.

Segunda situação: ao finalizar uma branch de feature. A maioria das equipes prefere merge (com a flag --no-ff) no main para registrar o momento de integração da feature. Isso simplifica a navegação pelo histórico e permite reverter facilmente uma feature inteira com um único git revert do commit de merge. O GitHub Flow por padrão oferece três opções de merge: merge simples, squash merge e rebase merge.

Terceira situação: ao trabalhar com um pull request revisado. GitHub e GitLab oferecem um botão de merge com diferentes opções. Merge (Create a merge commit) — histórico completo com um commit de merge. Squash and merge — histórico limpo sem detalhes de desenvolvimento. Rebase and merge — histórico linear sem commit de merge, mas com reescrita de commits. A escolha depende das regras da equipe.

• Branches públicas (main, develop) — apenas merge, nunca rebase.
• Finalização de PR — merge com --no-ff para marcar o ponto de integração.
• Branches com commits alheios — merge não reescreve o trabalho dos outros.
• Antes do lançamento — merge é mais seguro porque tem menos riscos.
• Branch compartilhada — se vários desenvolvedores trabalham em uma branch, o merge é obrigatório.

Melhores práticas para fusão de branches

Primeira regra: esteja sempre na versão mais recente da branch de destino antes de mesclar. Execute git checkout main && git pull antes de mesclar a branch de feature. Isso minimiza conflitos e garante que o commit de merge contenha todas as alterações mais recentes. Se a branch de destino avançou significativamente, primeiro execute git merge main dentro da branch de feature para resolver conflitos em seu contexto.

Segunda regra: teste o código após o merge. O merge pode alterar o comportamento mesmo sem conflitos. O pipeline de CI/CD deve executar testes no commit de merge antes de enviar para produção. Algumas equipes usam merge gates — verificações obrigatórias que bloqueiam o merge até que sejam aprovadas.

Terceira regra: documente os commits de merge. A mensagem padrão “Merge branch 'feature' into main” é pouco útil. Recomenda-se adicionar uma descrição do que foi mesclado: “Merge authentication module: login, registration, password recovery”. Isso simplifica a análise do histórico e a busca por regressões. Em projetos grandes, os commits de merge são gerados automaticamente a partir do título do PR.

• Atualização — antes de mesclar, certifique-se de que a branch de destino está atualizada (git pull).
• Testes — o CI/CD deve executar testes no commit de merge resultante.
• Mensagens descritivas — especifique no commit de merge qual feature foi mesclada.
• Frequência — mescle branches de feature o mais cedo e frequentemente possível (máximo uma semana).
• Reversão — git revert de um commit de merge reverte a feature inteira.