Merge e rebase

Trabalhou numa branch feature, o código está pronto. É preciso agora reintegrá-lo em main. O Git oferece dois mecanismos para isso: a fusão (merge) e o rebasamento (rebase).

Os dois atingem o mesmo objetivo — reunir o trabalho — mas com uma forma de histórico diferente. É todo o desafio desta lição.

Antes de qualquer integração, confirma-se que se tem a última versão:

git switch main
git pull origin main

O comando git merge reúne uma branch noutra. Existem dois casos.

Caso 1 — Fusão rápida (fast-forward): se main não se moveu desde a criação da branch, o Git avança simplesmente o ponteiro. Nenhum commit de fusão é criado.

Caso 2 — Fusão a três branches (three-way merge): se main recebeu novos commits entretanto, o Git cria um commit de fusão que tem dois pais.

# Colocar-se na branch alvo e depois fundir
git switch main
git merge feature/panier

# Forçar um commit de fusão mesmo que o fast-forward seja possível
git merge --no-ff feature/panier

O merge preserva a história real: vê-se quando e como as branches se juntaram. É honesto, mas o histórico pode tornar-se denso com muitos commits de fusão.

🔧 Mini-exercício — Quer fundir feature/panier em main forçando a criação de um commit de fusão, mesmo que um fast-forward fosse possível. Escreva o comando.

O git rebase desloca os commits da sua branch para os reproduzir por cima da ponta de outra branch. Resultado: um histórico linear, como se tivesse começado o trabalho depois dos últimos commits de main.

Antes do rebase:

Depois de git rebase main (os commits B e C são reproduzidos após D):

# Na branch feature, reproduzir por cima de main
git switch feature/panier
git rebase main

# Depois fusão fast-forward limpa em main
git switch main
git merge feature/panier

⚠️ Regra de ouro do rebase: nunca rebase commits já publicados e usados por outros. Está a reescrever a história, o que partiria os repositórios deles. O rebase é para o trabalho local não partilhado.

🔧 Mini-exercício — Está na branch feature/panier. Escreva o comando para reproduzir os seus commits por cima da ponta de main (histórico linear).

Um conflito ocorre quando o Git não consegue decidir automaticamente: duas branches modificaram a mesma linha do mesmo ficheiro. O Git pára e pede-lhe que decida.

O Git insere marcadores de conflito no ficheiro:

<<<<<<< HEAD
prix = 10   # versão de main
=======
prix = 12   # versão de feature
>>>>>>> feature/panier

A resolução passo a passo:

1. Abrir o ficheiro e escolher (ou combinar) a versão correta.
2. Apagar os marcadores <<<<<<<, =======, >>>>>>>.
3. Marcar o ficheiro como resolvido com git add.
4. Terminar a operação.

# Ver os ficheiros em conflito
git status

# Depois da edição manual
git add fichier-en-conflit.py

# Terminar um merge
git commit

# Terminar um rebase
git rebase --continue

# Em caso de pânico: anular tudo
git merge --abort      # ou: git rebase --abort

Um conflito não é um erro: é o Git a dizer-lhe, com honestidade, « não sei qual ficar, a decisão é sua ». Manter a calma e ler os marcadores chega em 99 % dos casos.

🔧 Mini-exercício — Editou o ficheiro app.py para resolver um conflito ocorrido durante um rebase. Que dois comandos terminam a operação?

git add app.py
git rebase --continue

Os dois reúnem o trabalho, mas produzem um histórico diferente. A escolha é muitas vezes uma convenção de equipa.

A prática recomendada mais habitual:

• Rebase a sua branch local em main antes de abrir uma pull request → histórico limpo.
• Merge a pull request em main → rasto claro da integração.

# 1. Limpar a branch local antes da PR
git switch feature/x
git rebase main

# 2. Depois da PR aprovada, o GitHub faz o merge

Frase mnemónica: « Rebase em privado, merge em público. » Rebasa-se o que é seu, funde-se o que é partilhado.

Question 1

O que faz git merge feature a partir de main quando main também tem novos commits?

a) Apaga a branch feature

b) Cria um commit de fusão com dois pais

c) Apaga o histórico

d) Recusa sempre fundir

Question 2

Qual é o efeito principal de um git rebase main?

a) Reproduzir os commits da branch por cima de main para um histórico linear

b) Clonar o repositório

c) Apagar main

d) Criar uma salvaguarda remota

Question 3

Por que não se deve rebasar uma branch já enviada e partilhada?

a) Porque o GitHub o proíbe

b) Porque isso reescreve os commits e parte os repositórios dos outros

c) Porque o rebase é mais lento

d) Porque apaga main

Question 4

O que representam os marcadores <<<<<<<, =======, >>>>>>>?

a) Comentários de código

b) Um erro de sintaxe Python

c) As zonas de um conflito a resolver à mão

d) O fim de um ficheiro

Question 5

Como anular com limpeza uma fusão bloqueada por conflitos?

a) git delete

b) git merge --abort

c) git reset --cloud

d) Apagar a pasta .git

Instrução

Duas branches modificam a mesma linha de um ficheiro config.txt. Reproduza o conflito e depois resolva-o ficando com as duas informações combinadas.

1. Em main, o ficheiro contém port = 8080.
2. Uma branch feature/ssl muda esta linha para port = 443.
3. Entretanto, main muda a mesma linha para port = 9090.
4. Funda feature/ssl em main, resolva o conflito ficando com port = 443 (HTTPS) e termine.

Correção

# Preparação: criar o conflito
echo "port = 8080" > config.txt
git add config.txt
git commit -m "Configuração inicial"

git switch -c feature/ssl
echo "port = 443" > config.txt
git commit -am "Passagem a HTTPS (porta 443)"

git switch main
echo "port = 9090" > config.txt
git commit -am "Alteração da porta para 9090"

# Tentativa de fusão → conflito
git merge feature/ssl

O Git mostra então:

Auto-merging config.txt
CONFLICT (content): Merge conflict in config.txt
Automatic merge failed; fix conflicts and then commit the result.

O ficheiro config.txt contém:

<<<<<<< HEAD
port = 9090
=======
port = 443
>>>>>>> feature/ssl

Edita-se para ficar só com o valor correto:

echo "port = 443" > config.txt   # decide-se a favor do HTTPS

git add config.txt
git commit -m "Fusão feature/ssl: conservação da porta 443"

Resultado esperado:

Truque: se se enganar a meio do conflito, git merge --abort devolve-lhe o repositório intacto. Não há risco em experimentar.

Pontos a reter

1. Merge e rebase reúnem duas branches, mas produzem um histórico diferente.
2. Merge preserva a história real; cria um commit de fusão com dois pais (exceto fast-forward).
3. Rebase reproduz os commits para um histórico linear e limpo.
4. Regra de ouro: rebase em privado, merge em público — nunca rebasar código partilhado.
5. Um conflito aparece quando a mesma linha é modificada dos dois lados: edita-se, faz-se add, termina-se.
6. Boa prática: rebasar a branch antes da PR e depois fazer merge da PR em main.

A continuação

Já sabe integrar o código tecnicamente. A lição 03 — Pull requests mostra como fazer reler este trabalho antes de o integrar, no centro da colaboração no GitHub.