Pull Requests são o coração da colaboração neste projeto. Este guia cobre o processo completo: da abertura até o merge.
- Branch a partir de
develop(oumainparahotfix/*). - Commits em Conventional Commits.
- Rode
npm run validatelocalmente — tudo verde. - Abra o PR usando o template
.github/PULL_REQUEST_TEMPLATE.md. - Garanta que o CI está verde.
- Aguarde 1 aprovação + resolução de comentários.
- Squash and merge mantendo o título do PR.
- A branch está atualizada com a base (
developoumain):git fetch origin git rebase origin/develop
-
npm run validateretorna 0 em todos os jobs. - Testes novos cobrem o que foi adicionado/corrigido.
-
CHANGELOG.mdfoi atualizado emUnreleased(se aplicável). -
docs/foi atualizado (API, arquitetura, decisões). - Não há
console.log, código comentado, ouanydesnecessário. - Screenshots/GIFs anexados para mudanças visuais.
Use o título do PR como mensagem de commit (será o commit do squash merge). Formato:
<tipo>(<escopo>): <descrição>
Exemplos:
feat(login): add remember-me checkboxfix(dashboard): correct kpi delta calculation
Use o template (.github/PULL_REQUEST_TEMPLATE.md). Preencha todos
os campos relevantes.
Aplique labels do labeler.yml (são sugeridas
automaticamente conforme os paths alterados) e adicione labels manuais
quando necessário:
kind:bug,kind:feature,kind:refactor,kind:chorearea:ui,area:auth,area:dashboard,area:infra,area:docspriority:high,priority:medium,priority:lowbreaking-change(se aplicável)
Para trabalhos em andamento, abra como Draft. Ele não será revisado até que você marque como "Ready for review".
<!-- markdownlint-disable -->
## 🚧 Status: WIP- Responda a todos os comentários (resolve a thread ou justifica).
- Não force-push após a primeira revisão (use
git push --force-with-leaseapenas se necessário e avise o revisor). - Mantenha o PR pequeno: < 400 linhas de diff idealmente. PRs grandes devem ser quebrados.
- Seja respeitoso e construtivo (veja Code of Conduct).
- Aprove explicitamente com o botão "Approve" — comentários sem aprovação não contam.
- Bloqueie com "Request changes" se houver impedimentos reais (segurança, bug, quebra de contrato).
- Foque em:
- Correção: faz o que se propõe?
- Testes: cobre casos de borda?
- Design: segue a arquitetura?
- Acessibilidade: navegável por teclado, ARIA correto?
- i18n: strings em PT-BR via
t(...), não hardcoded? - Performance: sem re-renders desnecessários, sem bundles inflados?
- PRs de bug ou hotfix: revisão em 1 dia útil.
- PRs de feature: revisão em 2 dias úteis.
- PRs de docs/chore: revisão em 3 dias úteis.
- ✅ CI verde (lint, typecheck, test, build).
- ✅ 1+ aprovação.
- ✅ Todas as threads resolvidas.
- ✅ Branch atualizada com a base.
- ✅ (Opcional) screenshots de antes/depois anexados.
Sempre via Squash and merge (mantém o histórico limpo e garante 1 commit por feature).
Depois do merge:
- Confirme que o commit aparece em
develop(oumain). - Delete a branch do remote (botão no GitHub).
- Se for release, siga o fluxo de
branches.md.
- CHANGELOG revisado antes do release.
- Tag criada em releases (v0.X.0).
- Milestone fechado.
- Issue relacionada fechada (com
Closes #NouFixes #Nno PR). - Comunicado no canal interno (Slack/Teams) com screenshots.
🚫 Não faça:
- Merge de PR próprio sem aprovação (em
main/develop). - Force-push após revisão sem aviso.
- Squash de PRs grandes — divida antes.
- Misturar
featcomfixno mesmo PR. - Ignorar comentários do revisor.
- Fazer merge com CI vermelho.
- Adicionar
WIPouDraftno título do PR (use o botão "Convert to draft").
- PR:
.github/PULL_REQUEST_TEMPLATE.md - Issue Bug:
.github/ISSUE_TEMPLATE/bug_report.md - Issue Feature:
.github/ISSUE_TEMPLATE/feature_request.md