Merge — o que é, tipos de fusão e mecanismo de funcionamento

O que é Merge?

Merge (fusão) é uma operação fundamental no Git que combina alterações de um branch (source) em outro (target). Como resultado da mesclagem, o branch alvo recebe todos os commits do branch fonte que ainda não estavam nele. Dependendo da situação, o Git pode executar o merge de três maneiras diferentes.

O principal valor do merge é preservar o histórico: o merge commit registra o fato da fusão de branches, preservando informações sobre quando e quais branches foram mesclados. Isso facilita a auditoria de alterações, a busca por regressões e a compreensão da cronologia do desenvolvimento. Em projetos grandes, o merge commit é a forma padrão de integração de código.

Segundo o GitLab Flow, merge commits são usados em 73% das equipes que trabalham com Git. Abordagens alternativas (rebase, squash) são preferidas por equipes focadas em histórico linear. A escolha da estratégia depende do tamanho da equipe, frequência de lançamentos e convenções aceitas no projeto.

Quando o Merge ocorre

Merge é necessário quando um desenvolvedor terminou de trabalhar em uma funcionalidade e deseja integrá-la ao develop ou main. Um cenário típico: um desenvolvedor criou um branch de funcionalidade a partir do develop, trabalhou nele por vários dias, e durante esse tempo novos commits de outros membros da equipe apareceram no develop. Antes de mesclar, é necessário combinar as alterações — e para isso se usa o merge.

Sem o merge, é impossível trabalhar colaborativamente em um único código no Git. Toda vez que dois desenvolvedores fazem alterações simultâneas em uma base de código, seus branches divergem. O merge é a única maneira de reunir essas alterações sem perda de dados.

Tipos de fusão no Git

O Git suporta três tipos de merge, cada um projetado para seu próprio cenário. A escolha do tipo de mesclagem afeta o histórico de commits, a facilidade de reversão e a legibilidade do log.

Fast-forward merge

Fast-forward ocorre quando o branch alvo não teve novos commits desde a criação do branch fonte. Neste caso, o Git simplesmente move o ponteiro do branch alvo para frente, para o último commit do branch fonte. O histórico permanece linear, sem merge commit.

# Fast-forward merge: develop não mudou desde a criação da feature
git checkout develop
git merge feature/new-login

# Resultado: o ponteiro do develop moveu-se para o final da feature
# Nenhum merge commit foi criado

Fast-forward é conveniente para branches de curta duração onde um desenvolvedor trabalhou sozinho. Mas esta abordagem tem uma desvantagem: perde-se a informação de que o branch existiu — todos os commits parecem feitos diretamente no develop.

Three-way merge

Three-way merge é executado quando ambos os branches têm novos commits após o ponto de divergência. O Git cria um merge commit separado com dois pais, que registra o fato da fusão dos branches. Esta abordagem é recomendada para branches de funcionalidade no desenvolvimento em equipe.

# Three-way merge forçado com a flag --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Um merge commit foi criado com a mensagem padrão
# Pode definir sua própria mensagem através de -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

A flag --no-ff garante a criação de um merge commit, mesmo que o fast-forward seja possível. Esta é uma boa prática para preservar informações de ramificação em um projeto.

Squash merge

Squash merge comprime todos os commits do branch fonte em um e o aplica ao alvo. O histórico da funcionalidade é perdido — um único commit com todas as alterações termina no branch. Isso é conveniente quando commits detalhados em um branch de funcionalidade não agregam valor ao histórico geral.

# Squash merge: todos os commits da feature são comprimidos em um
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash é adequado para rascunhos, branches experimentais e situações onde é importante manter um histórico limpo. A desvantagem é que a conexão com os commits originais é perdida, dificultando a reversão de alterações individuais.

Estratégias Ours e Theirs

Ours e Theirs são duas estratégias especiais de merge no Git. Ours ignora completamente as alterações do branch fonte, mantendo apenas o que está no alvo. Theirs, ao contrário, aceita a versão do branch fonte em qualquer conflito. Essas estratégias são úteis ao mesclar grandes volumes de código quando se sabe antecipadamente qual versão deve prevalecer.

Como funciona o Merge

O mecanismo de merge no Git é baseado na comparação de três pontos: o ancestral comum (merge base), o estado do branch fonte e o estado do branch alvo. O Git encontra o merge base — o último commit comum a ambos os branches — e calcula quais alterações ocorreram em cada branch após a divergência.

• Passo 1 — O Git determina o merge base: o último commit presente em ambos os branches
• Passo 2 — O Git constrói dois diffs: do merge base ao source e do merge base ao target
• Passo 3 — O Git tenta aplicar ambos os conjuntos de alterações ao merge base
• Passo 4 — Se as alterações não conflitarem — o merge é concluído automaticamente
• Passo 5 — Se houver conflito — o Git para e solicita resolução

O Git usa um algoritmo de mesclagem trilateral que considera não apenas as duas versões do arquivo comparadas, mas também seu ancestral comum. Graças a isso, o Git pode resolver automaticamente situações onde as alterações em um branch não afetam áreas modificadas do outro — mesmo que ambos os arquivos tenham sido modificados.

Exemplo de funcionamento do merge

Considere um cenário: dois desenvolvedores trabalham em arquivos diferentes em um mesmo branch de funcionalidade. O primeiro alterou LoginActivity.kt, o segundo alterou ProfileFragment.kt. Quando eles mesclam suas alterações, o Git vê que as alterações afetaram arquivos diferentes e realiza o merge automaticamente, sem intervenção humana.

Se ambos os desenvolvedores alteraram LoginActivity.kt, mas em métodos diferentes — o Git também lidará automaticamente, mesclando as alterações linha por linha. Um conflito surge apenas se ambos alteraram as mesmas linhas ou se um excluiu código que o outro modificou.

Resolução de conflitos no Merge

Um conflito de merge ocorre quando o Git não consegue mesclar automaticamente as alterações porque ambos os branches modificaram as mesmas linhas de maneira diferente. Neste caso, o Git marca as áreas conflitantes nos arquivos e aguarda a resolução manual do desenvolvedor.

As áreas de conflito são marcadas com marcadores especiais: <<<<<<< HEAD mostra o código do branch alvo, ======= é o separador, >>>>>>> source-branch mostra o código do branch fonte. O desenvolvedor deve escolher manualmente qual versão manter ou combiná-las.

# 1. Executar merge e ver o conflito
git merge feature/new-login
# Saída: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Ver a lista de arquivos com conflitos
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Resolver o conflito: editar o arquivo, remover marcadores
# 4. Adicionar o arquivo resolvido e finalizar o merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# ou: git commit (sem --continue)

Existem ferramentas para resolver conflitos: git mergetool abre um mesclador visual (Meld, Beyond Compare, VS Code). Muitos desenvolvedores preferem resolver conflitos na IDE — IntelliJ IDEA e Android Studio fornecem uma ferramenta integrada com comparação de três painéis que simplifica enormemente este processo.

Dicas para resolver conflitos: sempre entenda o que cada lado do conflito faz, não exclua código alheio sem entender sua lógica, e se o conflito for muito complexo — envolva os autores de ambos os branches em uma resolução conjunta.

Merge vs Rebase: quando escolher cada um

A escolha entre Merge e Rebase é uma das decisões arquitetônicas mais comuns no Git. Ambas as abordagens combinam alterações, mas fazem de maneira diferente: merge preserva o histórico de ramificação, rebase reescreve o histórico tornando-o linear.

• Merge — preserva o contexto: pode-se ver quando e de qual branch foi feita uma fusão. Melhor para branches públicos (develop, main) e trabalho em equipe
• Rebase — cria um histórico linear limpo sem merge commits extras. Melhor para branches de funcionalidade pessoais antes da revisão
• Regra: nunca faça rebase de branches públicos que outros desenvolvedores estejam usando

Muitas equipes usam uma abordagem híbrida: rebase para atualizar o branch de funcionalidade com develop (git rebase develop), e então merge com a flag --no-ff para registrar a fusão. Isso proporciona um histórico limpo dentro da funcionalidade e pontos de fusão informativos no nível do develop.