Skip to main content

Padrões de Pull Requests (PR)

Este guia define o processo oficial de criação, atualização e aprovação de Pull Requests no Frontend Smart NX (SNX).
O objetivo é manter um fluxo previsível, revisões técnicas eficazes e total rastreabilidade entre o código e as tarefas do Jira (NXS).

1. Nomenclatura e Estrutura de Branches​

1.1. Tipos de Branch​

TipoUsoExemplo
feature/Implementações de novas funcionalidadesfeature/NXS-2145-add-user-preferences
fix/Correções de bugs ou comportamentos inesperadosfix/NXS-2170-fix-modal-scroll
hotfix/Correções críticas aplicadas diretamente na mainhotfix/NXS-2201-critical-login-bug
history/Branch principal de uma história no Jira, que agrupa várias taskshistory/NXS-2100-dashboard-filters

Cada branch deve estar associada a um card no Jira no formato NXS-{número}.

1.2. Regras de Criação​

  • Sempre derive a branch a partir de develop.
  • Nomeie a branch com o prefixo correto seguido do ID da task e uma descrição curta em inglês.
  • Evite espaços, acentos ou caracteres especiais.

Exemplo completo:

git checkout develop
git pull origin develop
git checkout -b feature/NXS-2145-add-user-preferences

2. Regras de Pull Request​

  1. Toda PR deve apontar para develop como branch de destino. Nenhum PR deve ser aberto direto para main (exceto hotfixes críticos).

  2. A branch deve estar sempre atualizada com develop antes da aprovação.

    O autor é responsável por manter a branch sincronizada (git pull --rebase origin develop).

  3. Não é necessário descrever nada manualmente no corpo da PR. O título e a branch já são suficientes para identificação via Jira (NXS-####).

  4. O link com o Jira é feito automaticamente via padrão do nome da branch.

3. Critérios de Aprovação​

Uma Pull Request só pode ser mergeada quando atender todos os critérios abaixo:

CategoriaRegra
Review TécnicoAprovada por 1 desenvolvedor sênior ou por 2 membros da equipe.
Branch BasePR deve apontar para develop.
SincronizaçãoBranch deve estar atualizada com develop antes do merge.
Checks AutomáticosLint, build, testes e auditoria de dependências devem passar.
Política de MergeSempre usar “Squash and Merge” para manter histórico limpo.

Ninguém pode aprovar o próprio PR.

4. Critérios de Reprovação​

Um PR deve ser bloqueado ou solicitado ajustes quando:

SituaçãoAção
A branch está desatualizada com developSolicitar git pull --rebase origin develop antes do merge.
Quebra de build, lint ou testesCorrigir antes de nova revisão.
Código viola padrões definidos em /architecture/code-standards.mdAjustar conforme guia técnico.
Falta de cobertura mínima de testes (quando aplicável)Complementar testes antes de reabrir revisão.

5. Revisão de Código​

  • O reviewer deve focar em:

    • Clareza e consistência do código.
    • Coerência com os padrões do projeto.
    • Impacto no comportamento e performance.
    • Manutenção futura (simplicidade e coesão).

  • Feedbacks devem ser objetivos e técnicos, indicando o ponto exato e sugerindo melhoria.

  • Discussões devem acontecer dentro do PR, evitando comunicação fragmentada.

6. Política de Merge​

RegraDescrição
MétodoSempre usar Squash and Merge.
Mensagem de CommitDeve seguir o padrão automático com o ID do Jira (NXS-####).
Merge AutomáticoPermitido apenas após aprovação e checks verdes.
Branch CleanupBranches devem ser removidas após o merge.

7. Boas Práticas​

  • Prefira PRs pequenos e focados.

    PRs com mais de 500 linhas tornam a revisão ineficiente.

  • Evite misturar refactor com feature/fix.

  • Atualize sua branch frequentemente para evitar conflitos.

  • Valide localmente antes de abrir o PR (lint, build, test).

  • Nome da branch deve refletir o card do Jira — isso garante rastreabilidade no pipeline.

Histórico de Versões​

DataVersãoAutor / RevisorAlterações
08/04/2026v1.1.0Juathan Coelho DuartePadronização do prefixo history/ e alinhamento com novo fluxo
29/10/2025v1.0.0@Matheus TellesCriação inicial e estrutura base do documento