Mesclar branches — o que é, estratégias de merge e resolução de conflitos

O que é merge no Git

Merge no Git é a operação de combinar dois ou mais históricos de desenvolvimento em um. Quando um desenvolvedor mescla um branch, o Git encontra automaticamente o ancestral comum (base commit) e cria um novo commit de merge que inclui alterações de ambos os branches. Three-way merge é o algoritmo padrão que compara três estados: o ancestral comum, o primeiro branch e o segundo branch.

O processo de merge começa com o comando git merge. O Git determina o ponto de divergência dos branches e aplica sequencialmente as alterações do branch de origem sobre o branch de destino. Se as alterações não entrarem em conflito, o Git realiza um fast-forward ou cria um merge commit dependendo das configurações. Fast-forward é um cenário onde o branch de destino simplesmente avança para os commits do branch de origem.

# Mudar para o branch de destino e mesclar
git checkout main
git merge feature/payment-module

# Mesclar com no-fast-forward explícito
git merge --no-ff feature/payment-module

# Abortar merge se os conflitos forem muito complexos
git merge --abort

A flag --no-ff (no fast-forward) força a criação de um merge commit mesmo quando um fast-forward é possível. Isso preserva a informação de que as alterações foram feitas em um branch separado. Muitas equipes preferem esta abordagem para manter o histórico de ramificação de forma explícita.

Métodos de fusão de branches

O Git tem três estratégias principais de fusão de branches, cada uma adequada para um cenário específico. A escolha da estratégia depende da cultura da equipe e dos requisitos de limpeza do histórico do projeto.

Standard merge cria um merge commit com dois pais. O histórico completo é preservado, mas o grafo de ramificação se torna mais complexo. Squash merge combina todos os commits de um branch de funcionalidade em um e o aplica sobre o branch de destino — o histórico se torna linear e limpo, mas a informação sobre estágios intermediários é perdida.

Rebase, embora não seja um merge completo, atinge o mesmo resultado — as alterações de um branch são movidas para cima de outro. A diferença é que o histórico é reescrito: os commits do branch de funcionalidade são recriados sobre o último commit do branch de destino. Isso dá um histórico perfeitamente linear, mas requer force push ao enviar.

Como resolver conflitos no merge

Um conflito de merge surge quando as mesmas linhas de um arquivo são alteradas em dois branches. O Git não pode determinar automaticamente qual versão manter e requer intervenção do desenvolvedor. Os conflitos são exibidos nos arquivos usando marcadores especiais: <<<<<<<, =======, >>>>>>>.

O processo de resolução de conflitos envolve várias etapas. Primeiro, o desenvolvedor abre o arquivo em conflito e seleciona manualmente as alterações necessárias. É importante não apenas escolher uma versão, mas entender a lógica de ambas as alterações e tomar uma decisão correta. Após editar o arquivo, os marcadores de conflito são removidos e as alterações são adicionadas à staging area via git add.

# Ver lista de arquivos em conflito
git status

# Iniciar mergetool (ex.: VS Code, IntelliJ)
git mergetool

# Depois de resolver todos os conflitos
git add .
git merge --continue

# Ou abortar o merge completamente
git merge --abort

Usar ferramentas visuais de merge acelera significativamente a resolução de conflitos. VS Code, IntelliJ IDEA e GitKraken fornecem interfaces com três painéis: branch atual, branch de entrada e resultado. A ferramenta git mergetool abre automaticamente o editor configurado para cada arquivo em conflito.

A melhor forma de evitar conflitos complexos é a sincronização regular do branch de funcionalidade com o branch principal. Se um desenvolvedor mescla main em seu branch uma vez por dia, os conflitos serão pequenos e facilmente resolvíveis. Acumular alterações por uma semana garante conflitos complexos com alto risco de erros.

Quando usar rebase em vez de merge

Rebase e merge são duas formas de combinar alterações, e a escolha entre eles frequentemente gera debates nas equipes. Rebase move commits de um branch para cima de outro, reescrevendo o histórico. Merge cria um novo commit de merge, preservando o histórico de ramificação. Cada abordagem tem suas vantagens e limitações.

Rebase é apropriado quando um desenvolvedor está trabalhando em seu branch de funcionalidade local e quer um histórico linear limpo antes de criar um Pull Request. Após o rebase, todos os commits são organizados sequencialmente sem commits de merge desnecessários. No entanto, rebase requer force push e não é aplicável a branches onde várias pessoas trabalham simultaneamente.

• Rebase — para branches de funcionalidade pessoais onde é necessário um histórico limpo
• Merge — para branches compartilhados e para registrar o momento da fusão
• Squash — quando um branch de funcionalidade contém muitos commits pequenos de rascunho

A regra de ouro do Git: não use rebase em commits que já foram enviados para o repositório compartilhado. Isso garante que o histórico no branch compartilhado permaneça inalterado e que outros desenvolvedores não encontrem commits duplicados ou perdidos. Para integrar um branch de funcionalidade ao branch principal, use merge via Pull Request.

Melhores práticas de fusão de branches

Um processo de merge adequado é a base do desenvolvimento estável. No trabalho em equipe moderno, a fusão não é feita através do console, mas sim via Pull Request no GitHub ou Merge Request no GitLab. Um PR passa por revisão de código, verificações automáticas de CI e só então é mesclado ao branch principal.

A primeira prática — mesclar apenas depois que todas as verificações passarem. O pipeline de CI deve compilar o projeto, executar testes e verificar a qualidade do código. Se pelo menos uma verificação falhar, o merge é bloqueado. As plataformas modernas (GitHub, GitLab) têm proteção integrada: branch protection rules bloqueiam automaticamente o merge se o CI falhar.

A segunda prática — nunca mesclar código quebrado. Antes do merge, o desenvolvedor deve garantir que suas alterações não quebrem a compilação nem regressionem a funcionalidade existente. Para isso existem testes automáticos e revisão de código.

A terceira prática — limpar os branches de funcionalidade após o merge. Um branch que já foi mesclado deve ser excluído. Isso evita confusão e desordem no repositório. O GitHub oferece automaticamente a exclusão do branch após o merge de um PR, e as configurações do repositório podem ser ajustadas para exclusão automática.