Rebase ou merge: a regra que resolve a discussão

É das discussões mais antigas em qualquer equipa, e tem uma regra simples por baixo de todo o barulho.

1. O que cada um faz

O merge junta dois ramos com um commit novo. A história fica como aconteceu: dois caminhos que se encontraram.

*   9f2a1b  merge do ramo funcionalidade
|\
| * 7b2e44  acrescenta validação
| * a3f9c2  primeiro esboço
|/
* 4c1d09  versão 1.4.0

O rebase reescreve os seus commits como se tivessem nascido a partir da ponta atual. A história fica uma linha só:

* 8e4b17  acrescenta validação
* 2a9c33  primeiro esboço
* 4c1d09  versão 1.4.0

Repare nos identificadores: são outros. O rebase não move os commits, cria commits novos com o mesmo conteúdo.

2. A regra de ouro

É esta, e resolve 90% dos casos:

Nunca reescreva história que já esteja partilhada.

No seu ramo, antes de o publicar, faça rebase à vontade — arrume os commits, junte os "corrige typo", ponha aquilo apresentável. A partir do momento em que outra pessoa tem esse ramo na máquina dela, reescrever obriga-a a resolver um problema que não criou.

3. Na prática, o dia-a-dia

# Trazer o trabalho dos outros sem criar commits de merge inúteis
git pull --rebase

# Ou de vez, na configuração
git config --global pull.rebase true

Um git pull normal, quando há trabalho dos dois lados, cria um commit de merge que não diz nada a ninguém. Vinte desses tornam a história ilegível.

4. Limpar antes de submeter

# Juntar, reordenar ou reescrever os últimos três commits
git rebase -i HEAD~3

Vale a pena o hábito: quem revê o código lê os commits. Uma sequência de "wip", "wip2" e "agora vai" custa a quem lê. Três commits com uma ideia cada custam metade do tempo a rever.

E se algo correr mal a meio de um rebase, o git rebase --abort devolve tudo ao estado anterior. Não há nada de irreversível — desde que se cumpra a regra de ouro.