Branches e estratégias de branching

Uma branch é uma linha de desenvolvimento independente. Permite trabalhar numa nova funcionalidade ou numa correção sem tocar no código estável que os outros usam.

Pense numa branch como num rascunho separado. Pode fazer nela todas as tentativas que quiser; enquanto não fundir, o trabalho dos outros não é afetado.

Sem branches, toda a equipa escreveria no mesmo ficheiro ao mesmo tempo: caos garantido. Com as branches, cada um avança no seu corredor e depois junta-se com limpeza.

Os comandos de base já vistos no módulo 01:

# Criar uma branch e mudar para ela
git switch -c feature/login

# Listar as branches
git branch

# Voltar a main
git switch main

🔧 Mini-exercício — Escreva o comando moderno para criar uma branch feature/login e mudar para ela de uma só vez.

Numa equipa, não se criam branches ao acaso: dá-se-lhes um papel e um nome convencional. Eis os tipos mais difundidos.

Exemplos de nomes realistas:

feature/ajout-paiement-stripe
feature/dashboard-utilisateur
release/1.4.0
hotfix/correction-faille-login

Uma boa convenção de nomes é documentação gratuita: só pelo nome da branch, a equipa sabe do que se trata.

🔧 Mini-exercício — Tem de corrigir com urgência uma falha de início de sessão em produção. Que prefixo de branch usa, e proponha um nome completo.

O Git Flow é uma estratégia estruturada introduzida por Vincent Driessen em 2010. Assenta em duas branches permanentes (main e develop) e três tipos de branches temporárias (feature, release, hotfix).

O ciclo típico:

1. Parte-se de develop para criar uma branch feature/*.
2. Quando está pronta, a feature é fundida em develop.
3. Quando há funcionalidades suficientes, cria-se uma release/* para estabilizar.
4. A release é fundida em main (e etiquetada) e em develop.
5. Um bug crítico em produção? Cria-se um hotfix/* a partir de main e depois funde-se em main e develop.

# Iniciar uma funcionalidade (sem a extensão git-flow)
git switch develop
git switch -c feature/panier

# ... trabalho + commits ...

git switch develop
git merge feature/panier
git branch -d feature/panier

O Git Flow brilha em software entregue por versões (apps móveis, software instalado). Para um sítio web implantado 10 vezes por dia, torna-se um travão.

O GitHub Flow é uma estratégia simples e leve, pensada para a implantação contínua. Uma só branch permanente: main. Todo o resto passa por branches feature curtas e por pull requests.

As regras de ouro:

1. main é sempre implantável.
2. Para qualquer trabalho, cria-se uma branch descritiva a partir de main.
3. Faz-se commit com regularidade e abre-se uma pull request (vista na lição 03).
4. Depois da revisão e dos testes verdes, funde-se em main.
5. Implanta-se imediatamente main.

git switch main
git pull
git switch -c feature/filtre-recherche
# ... commits ...
git push -u origin feature/filtre-recherche
# → abrir uma Pull Request no GitHub

O GitHub Flow é provavelmente o melhor ponto de partida para uma equipa moderna: estrutura suficiente para colaborar, leveza suficiente para ir depressa.

🔧 Mini-exercício — Em GitHub Flow, escreva os dois comandos para partir de um main atualizado antes de criar a sua branch de trabalho.

git switch main
git pull

O Trunk-Based Development (desenvolvimento no tronco) leva a simplicidade ainda mais longe: toda a gente integra o seu trabalho numa única branch (o trunk, ou seja main) com muita frequência — idealmente várias vezes por dia.

Princípios-chave:

• As branches de funcionalidade são minúsculas e vivem menos de um dia.
• As funcionalidades não concluídas ficam escondidas atrás de feature flags (bandeiras) em vez de branches longas.
• A integração contínua (CI) é obrigatória: cada commit dispara build + testes.

# Ciclo ultracurto
git switch main
git pull
# pequena alteração...
git commit -am "Adiciona o botão de exportação"
git push      # integrado no tronco minutos depois

O pior inimigo das equipas Git são as branches que vivem semanas. Quanto mais tarde se integra, mais dolorosa é a fusão. O trunk-based resolve isto ao integrar cedo e com frequência.

🔧 Mini-exercício — Em Trunk-Based, como integra uma funcionalidade não concluída sem bloquear os outros nem criar uma branch longa?

Não existe estratégia universal: a boa escolha depende do tipo de produto, da maturidade da equipa e da frequência de implantação.

Conselho: a maior parte das equipas deveria começar pelo GitHub Flow. Oferece o melhor compromisso simplicidade / segurança. Migra-se para o trunk-based quando a CI está madura, ou para o Git Flow só se o produto impuser versões.

Question 1

Para que serve principalmente uma branch Git?

a) Para salvaguardar o repositório na cloud

b) Para trabalhar de forma isolada sem afetar o código estável

c) Para comprimir os ficheiros

d) Para apagar o histórico

Question 2

Quantas branches permanentes o Git Flow utiliza?

a) Uma só (main)

b) Duas (main e develop)

c) Nenhuma

d) Uma por programador

Question 3

Qual a estratégia mais adequada a um sítio web implantado várias vezes por dia?

a) Git Flow

b) GitHub Flow ou Trunk-Based

c) Nenhuma branch de todo

d) Uma branch por ano

Question 4

No Trunk-Based Development, como se esconde uma funcionalidade não concluída?

a) Numa branch longa de várias semanas

b) Com um feature flag (bandeira de funcionalidade)

c) Apagando o código todas as noites

d) Não se pode, é preciso acabar tudo de uma vez

Question 5

Que prefixo de branch se usa para corrigir um bug crítico diretamente em produção?

a) feature/

b) release/

c) hotfix/

d) develop/

Instrução

Trabalha num repositório cuja main é estável. Pedem-lhe que acrescente uma página « Sobre ». Ponha em prática o GitHub Flow:

1. Parta de um main atualizado.
2. Crie uma branch de funcionalidade bem nomeada.
3. Faça um commit que acrescenta o ficheiro apropos.html.
4. Envie a branch para o repositório remoto para preparar uma pull request.
5. Liste as suas branches para verificar.

Correção

# 1. Partir de um main atualizado
git switch main
git pull origin main

# 2. Criar uma branch descritiva
git switch -c feature/page-apropos

# 3. Criar o ficheiro e depois fazer commit
echo "<h1>Sobre</h1>" > apropos.html
git add apropos.html
git commit -m "Adiciona a página Sobre"

# 4. Enviar a branch para o remoto
git push -u origin feature/page-apropos

# 5. Verificar as branches
git branch

Resultado esperado:

* feature/page-apropos
  main

Etapa seguinte lógica: abrir uma pull request no GitHub para fazer reler e fundir este trabalho — é exatamente o objeto da lição 03.

Pontos a reter

1. Uma branch isola o trabalho sem afetar o código estável.
2. Tipos de branches: main, develop, feature/, release/, hotfix/ — cada um com um papel.
3. Git Flow: estruturado, duas branches permanentes, ideal para versões planeadas.
4. GitHub Flow: simples, uma branch main + pull requests, perfeito para a web.
5. Trunk-Based: integração muito frequente no tronco, exige uma CI sólida.
6. A escolha depende do produto, da equipa e da frequência de implantação.

A continuação

Agora que sabe organizar as suas branches, siga para a lição 02 — Merge e rebase: como juntar estas branches com limpeza e resolver os conflitos.