Merge vs Rebase - Estudo de Caso — Git avançado e GitHub

Índice

O problema
Solução 1: Merge
Solução 2: Rebase
Comparação prática
Que abordagem escolher?

1. O problema

Situação típica:

Desenvolve em feature-branch
Entretanto, main avança (colegas fazem push)
Quer integrar o seu trabalho em main

2 estratégias possíveis:

MERGE: fundir as branches
REBASE: reescrever o histórico

Voltar ao índice

2. Solução 1: Merge

Setup do cenário:

bash

mkdir demo-merge && cd demo-merge && git init

# Base comum
echo "print('app v1')" > app.py
git add . && git commit -m "Versão inicial"

# Branch feature
git checkout -b feature-login  
echo "print('login system')" > login.py
git add . && git commit -m "Add login"
echo "print('login v2')" > login.py  
git add . && git commit -m "Improve login"

# Main avança entretanto
git checkout main
echo "print('app v1.1')" > app.py
git add . && git commit -m "Update main app"

Merge:

bash

git merge feature-login

Resultado Merge:

*   Merge branch 'feature-login'
|\  
| * Improve login
| * Add login  
* | Update main app
|/  
* Version initiale

Histórico: mostra claramente que houve 2 linhas de desenvolvimento em paralelo.

Voltar ao índice

3. Solução 2: Rebase

Setup idêntico, estratégia diferente:

bash

mkdir demo-rebase && cd demo-rebase && git init

# O mesmo setup de antes...
echo "print('app v1')" > app.py
git add . && git commit -m "Versão inicial"

git checkout -b feature-login  
echo "print('login system')" > login.py
git add . && git commit -m "Add login"
echo "print('login v2')" > login.py  
git add . && git commit -m "Improve login"

git checkout main
echo "print('app v1.1')" > app.py
git add . && git commit -m "Update main app"

Rebase:

bash

git checkout feature-login
git rebase main              # "Desloca" os seus commits depois de main
git checkout main  
git merge feature-login      # Fast-forward merge

Resultado Rebase:

* Improve login
* Add login  
* Update main app
* Version initiale

Histórico: linear, como se tivesse desenvolvido depois das atualizações de main.

Voltar ao índice

4. Comparação prática

Aspeto	MERGE	REBASE
Histórico	Mostra branches paralelas	Linear, limpo
Commit de merge	Sim, criado automaticamente	Não, fast-forward
Complexidade	Simples	Mais complexa
Conflitos	Resolver 1 vez	Talvez várias vezes
Rastreabilidade	Vê quando a feature foi criada/fundida	Como se tivesse sido desenvolvido sequencialmente

Visualização lado a lado:

MERGE:

    A---B---C main
   /         \
  D---E---F---G feature (merge commit G)

REBASE:

A---B---C---D'---E'---F' main (commits D,E,F "deslocados")

Voltar ao índice

5. Que abordagem escolher?

Use MERGE quando:

Está a começar com Git
Quer manter o histórico « verdadeiro »
A equipa trabalha em branches de longa duração
Segurança em primeiro lugar

Comando:

bash

git checkout main
git merge feature-branch

Use REBASE quando:

Quer um histórico limpo e linear
Feature branch curta e pessoal
A equipa prefere um histórico « story-like »
Domina bem o Git

Comando:

bash

git checkout feature-branch
git rebase main
git checkout main
git merge feature-branch    # Fast-forward

REGRA DE OURO:

NUNCA rebase commits já partilhados/enviados!

Recomendação simples:

Principiante → sempre MERGE
Confirmado → REBASE em branches pessoais, MERGE para partilhar

Os dois funcionam. O importante = coerência na equipa!