Branches, commits e Pull Requests que passam em revisão

Para a maioria dos times, trunk-based com branches curtas vence fluxos complexos: você cria feat/algo, entrega em menos de dois dias, abre PR, o CI valida e o merge acontece. Branches longas acumulam conflito e transformam integração em evento traumático.

Commits são documentação. Conventional Commits (feat, fix, chore, docs, refactor) permitem gerar changelog automático e dizem ao leitor a intenção da mudança. Um bom commit responde o que mudou e por quê; o como está no diff.

Proteger a main é decisão de engenharia, não burocracia: exigir PR, revisão e checks impede que código sem teste chegue à produção. É também o ponto onde CI/CD começa a ter valor real.

1. O modelo mental do Git

O Git guarda snapshots, não diferenças. Cada commit aponta para o snapshot e para o commit pai; uma branch é apenas um ponteiro móvel para um commit. Entender isso elimina o medo: criar branch é barato e quase nada se perde de verdade.

2. As três áreas

Working tree (seus arquivos), staging (o que vai no próximo commit, via git add) e repositório (commits). git add -p permite escolher trechos, produzindo commits pequenos e focados.

3. Mensagens de commit que ajudam no incidente

Use o padrão Conventional Commits: feat(api): adiciona endpoint /orders, fix(nginx): aumenta proxy_read_timeout. Linha de assunto no imperativo, até ~72 caracteres, e corpo explicando o porquê. Ferramentas geram changelog e versão a partir disso.

4. Fluxo de trabalho com trunk-based

Branches curtas (horas ou poucos dias) saindo da main, PR pequeno, revisão, CI verde, merge. Branches longas acumulam conflito e risco. Feature flags permitem integrar código incompleto sem ativá-lo.

5. Pull Request que passa em revisão

Título claro e descrição com contexto, mudança e como testar
Menos de ~400 linhas alteradas
CI verde antes de pedir revisão
Screenshots ou saída de comandos quando for infra
Proteção de branch: revisão obrigatória e checks exigidos

6. Checagem final

Você deve criar branch, fazer commits atômicos com add -p, abrir PR bem descrito e explicar o que é uma branch por dentro.

Na prática

Fluxo diário

bash

git switch -c feat/health-endpoint
git add src/routes/health.js
git commit -m "feat(api): adiciona endpoint /health com checagem de banco"
git push -u origin feat/health-endpoint

gh pr create --fill --base main
gh pr checks
gh pr merge --squash --delete-branch

git log --oneline --graph --decorate -10

Ciclo completo de uma mudança

bash

git switch main && git pull --ff-only
git switch -c fix/nginx-timeout
git add -p                          # escolhe trechos
git commit -m "fix(nginx): ajusta proxy_read_timeout para 15s" \
  -m "p99 da rota /orders medido em 11s; timeout anterior de 5s gerava 504."
git push -u origin fix/nginx-timeout
gh pr create --fill --base main     # abre o PR com a mensagem do commit

Por que isso importa

Pipelines, GitOps e rollback dependem de histórico previsível. Repositório caótico contamina toda a automação.

Erro comum

Commitar tudo em um único commit gigante com mensagem 'ajustes'.

Dica de produção

Squash merge mantém a main limpa e facilita revert de uma mudança inteira.

Alerta de segurança

Ative varredura de segredos no repositório; token commitado deve ser revogado, não apenas removido.

Pergunta de entrevista

Como você organizaria o fluxo de branches de um time de cinco pessoas?

Branches, commits e Pull Requests que passam em revisão

Objetivos desta aula

1. O modelo mental do Git

2. As três áreas

3. Mensagens de commit que ajudam no incidente

4. Fluxo de trabalho com trunk-based

5. Pull Request que passa em revisão

6. Checagem final

Na prática

Glossário

Conexão com o CloudShop

Quiz da aula

Minhas anotações