Git Rebase vs. Merge: Entendendo as Diferenças e Quando Usar

git merge e git rebase ambos trazem trabalho de uma branch para outra, mas deixam históricos muito diferentes. Escolha o errado em uma branch compartilhada e você pode dificultar a vida de todos que já puxaram seus commits.

Este guia explica o que cada comando faz, como ele altera o histórico de commits e quando você deve usar merge ou rebase em um fluxo de trabalho em equipe.

O que é git merge?

git merge é a maneira mais comum e direta de integrar mudanças de uma branch em outra. Quando você mescla a branch B na branch A, o Git procura um commit ancestral comum entre A e B. Em seguida, ele cria um novo commit (um commit de merge) na branch A que tem dois pais: a ponta de A e a ponta de B. Este commit de merge encapsula todas as mudanças introduzidas em B desde o ancestral comum.

Características principais de git merge:

• Preserva o Histórico: git merge cria um commit de merge, que registra explicitamente quando e onde duas branches foram unidas. Isso preserva o contexto histórico do seu desenvolvimento, mostrando os pontos de ramificação e mesclagem.
• Não destrutivo: Ele não reescreve commits existentes. Os commits originais em ambas as branches permanecem intocados.
• Cria Commits de Merge: Cada merge resulta em um novo commit, o que pode levar a um histórico de commits mais complexo e não linear, muitas vezes visualizado como um gráfico com múltiplas branches divergindo e convergindo.

Exemplo de git merge:

Digamos que você tenha uma branch main e crie uma branch feature a partir dela. Você faz alguns commits em feature e, enquanto isso, novos commits são adicionados a main.

# Estado inicial:
# A -- B -- C (main)
#      \
#       D -- E (feature)

# Mude para a branch main
git checkout main

# Mescle a branch feature na main
git merge feature

# Estado resultante:
# A -- B -- C -- F (main)
#      \       /
#       D -- E (feature)
# Onde F é o commit de merge com os pais C e E

Neste cenário, o commit F é um commit de merge que traz as mudanças de E para main. A branch feature ainda existe independentemente.

O que é git rebase?

git rebase, por outro lado, é uma maneira de integrar mudanças de uma branch em outra reescrevendo seu histórico de commits. Quando você faz rebase da branch B na branch A, o Git pega os commits que são exclusivos de B, armazena-os temporariamente, redefine B para a ponta de A e, em seguida, reaplica os commits armazenados um por um em cima de A.

Características principais de git rebase:

• Reescreve o Histórico: git rebase cria novos commits com o mesmo conteúdo dos originais, mas com novos IDs de commit. Isso faz com que o histórico de commits pareça linear, como se a branch de feature tivesse sido desenvolvida sequencialmente após as últimas mudanças na branch de destino.
• Evita Commits de Merge: Geralmente evita criar commits de merge, resultando em um histórico mais limpo e linear.
• Pode ser destrutivo: Como reescreve o histórico, git rebase deve ser usado com cautela, especialmente em branches que foram compartilhadas com outras pessoas.

Exemplo de git rebase:

Usando o mesmo cenário acima:

# Estado inicial:
# A -- B -- C (main)
#      \
#       D -- E (feature)

# Mude para a branch feature
git checkout feature

# Faça rebase da branch feature na main
git rebase main

# Estado resultante:
# A -- B -- C (main)
#           \
#            D' -- E' (feature)
# Onde D' e E' são novos commits com o mesmo conteúdo de D e E

Após fazer rebase de feature em main, os commits D e E são reproduzidos em cima do commit C. A branch feature agora começa a partir do commit mais recente em main, e o histórico é linear. Os commits originais D e E são efetivamente abandonados (embora recuperáveis por um tempo).

Rebase vs. Merge: Principais Diferenças Resumidas

Característica	git merge	git rebase
Histórico	Preserva o histórico original; cria commits de merge	Reescreve o histórico; cria um histórico linear
IDs de Commit	Commits originais permanecem inalterados	Novos commits são criados; os antigos são abandonados
Colaboração	Seguro para branches compartilhadas	Arriscado para branches compartilhadas; use em branches locais/privadas
Complexidade	Pode levar a um histórico complexo e não linear	Cria um histórico mais simples e linear
Propósito	Integra mudanças mantendo o contexto	Integra mudanças reaplicando-as sequencialmente

Quando Usar git merge

git merge é geralmente a escolha mais segura e comum, especialmente para integrar mudanças em branches de longa duração ou ao colaborar com uma equipe em uma branch compartilhada.

• Integrando em main/master: Quando você deseja trazer uma branch de feature concluída para sua linha de desenvolvimento principal (main ou master), a mesclagem é frequentemente preferida. Isso preserva o contexto do desenvolvimento da branch de feature e marca explicitamente seu ponto de integração.
• Branches Compartilhadas: Se você está trabalhando em uma branch que é compartilhada com outros membros da equipe, git merge é quase sempre a escolha correta. Fazer rebase de uma branch compartilhada pode causar problemas significativos para seus colaboradores, pois reescreve um histórico no qual eles podem já ter baseado seu trabalho.
• Preservando o Histórico de Lançamento: Para branches importantes, como branches de lançamento, manter um histórico claro e imutável com commits de merge pode ser benéfico para auditoria e compreensão de lançamentos passados.

Cenário: Mesclando uma feature concluída em main

# Suponha que você esteja na branch 'main' e sua branch de feature esteja atualizada
git checkout main
git merge nome-da-branch-feature

Isso criará um commit de merge em main incorporando todas as mudanças de nome-da-branch-feature.

Quando Usar git rebase

git rebase é poderoso para manter suas branches locais atualizadas com uma branch principal e para limpar seu próprio histórico de commits antes de compartilhá-lo.

• Atualizando Branches de Feature Locais: Se você criou uma branch de feature e a branch main avançou, fazer rebase da sua branch de feature em main permite incorporar essas mudanças upstream sem criar um commit de merge imediato. Isso mantém os commits da sua branch de feature logicamente sequenciais.
• Limpando o Histórico Local (Rebase Interativo): git rebase -i (rebase interativo) é inestimável para organizar seus próprios commits antes de enviá-los. Você pode comprimir vários commits pequenos em um, reordenar commits, editar mensagens de commit ou até mesmo excluir commits.
• Mantendo um Histórico de Projeto Linear: Se sua equipe adota um fluxo de trabalho que prioriza um histórico limpo e linear, fazer rebase das branches de feature em main antes de mesclar pode conseguir isso. No entanto, isso requer adesão estrita à regra de não fazer rebase em branches compartilhadas.

Cenário: Atualizando sua branch de feature com mudanças upstream

# Suponha que você esteja na sua branch 'feature' e 'main' tenha novos commits
git checkout main             # Mude para main
git pull origin main        # Certifique-se de que main está atualizada
git checkout feature        # Volte para sua branch de feature
git rebase main             # Reproduza seus commits de feature em cima da main mais recente

Agora, sua branch feature está baseada na main mais recente, e quando você eventualmente mesclar feature de volta em main, será um merge fast-forward (nenhum commit de merge necessário se nenhum novo commit foi feito em main desde seu rebase).

Cenário: Limpando seus commits locais (Rebase Interativo)

# Suponha que você fez vários commits pequenos em sua branch de feature
git checkout nome-da-branch-feature
git rebase -i HEAD~3      # Faça rebase dos últimos 3 commits interativamente

Isso abrirá um editor onde você pode escolher pick, reword, edit, squash, fixup ou drop seus commits, permitindo consolidá-los em um conjunto mais significativo.

Melhores Práticas e Avisos

• Não faça rebase em branches compartilhadas/públicas: Fazer rebase em branches que outras pessoas já puxaram e basearam seu trabalho fará com que o histórico delas divirja do seu. Use git merge para branches públicas ou compartilhadas, a menos que sua equipe tenha um fluxo de trabalho explícito de force-push.
• Faça Rebase em Suas Próprias Branches: Rebase é excelente para suas branches de feature locais e privadas para mantê-las limpas e atualizadas. Depois de estar satisfeito com suas mudanças locais, você pode mesclá-las em uma branch compartilhada.
• Entenda o Impacto: Antes de executar git rebase, certifique-se de entender que ele reescreve o histórico. Se você não tiver certeza, git merge é sempre a opção mais segura.
• Considere o Fluxo de Trabalho da Sua Equipe: Discuta com sua equipe qual estratégia (merge vs. rebase) eles preferem ou o que seu fluxo de trabalho definido dita.
• Histórico Limpo é Importante: Embora git merge preserve o histórico, um histórico cheio de muitos commits de merge pequenos e insignificantes pode se tornar ruidoso. git rebase pode ajudar a criar um histórico mais limpo e legível, especialmente para branches de feature antes de serem mescladas.

Conclusão

Use git merge quando preservar o histórico compartilhado for importante. Use git rebase para atualizar ou limpar sua própria branch local antes que outras pessoas dependam dela. Quando você não tiver certeza se outra pessoa baseou trabalho em sua branch, mescle em vez de fazer rebase.