Criar Pull Request
Criar pull requests seguindo as práticas de engenharia do Sentry.
Requer: GitHub CLI (gh) autenticada e disponível.
Processo
Passo 1: Verificar Estado da Branch
# Verificar branch atual e status
git status
git log main..HEAD --oneline
Garanta que:
- Todas as mudanças estão commitadas
- A branch está atualizada com o remoto
- As mudanças estão rebased em main, se necessário
Passo 2: Analisar Mudanças
Revise o que será incluído no PR:
# Ver todos os commits que entrarão no PR
git log main..HEAD
# Ver o diff completo
git diff main...HEAD
Compreenda o escopo e a finalidade de todas as mudanças antes de escrever a descrição.
Passo 3: Escrever a Descrição do PR
Siga esta estrutura:
<descrição breve do que o PR faz>
<por que essas mudanças estão sendo feitas - a motivação>
<abordagens alternativas consideradas, se houver>
<qualquer contexto adicional que os revisores precisem>
NÃO inclua:
- Seções "Plano de testes"
- Listas de checkboxes com passos de testes
- Resumos redundantes do diff
Inclua:
- Explicação clara do quê e por quê
- Links para issues ou tickets relevantes
- Contexto que não é óbvio no código
- Notas sobre áreas específicas que precisam de revisão cuidadosa
Passo 4: Criar o PR
gh pr create --title "<tipo>(<escopo>): <descrição>" --body "$(cat <<'EOF'
<corpo da descrição aqui>
EOF
)"
Formato do título segue convenções de commit:
feat(escopo): Adicionar nova funcionalidadefix(escopo): Corrigir o bugref: Refatorar algo
Passo 5: Adicionar Revisores (se conhecido)
# Solicitar revisão de pessoas específicas
gh pr edit --add-reviewer usuario1,usuario2
# Ou solicitar de um time
gh pr edit --add-reviewer @getsentry/nome-do-time
Limite a 1-3 revisores para manter clara a propriedade.
Exemplos de Descrição de PR
PR de Funcionalidade
Adicionar respostas em thread do Slack para notificações de alerta
Quando um alerta é atualizado ou resolvido, agora postamos uma resposta
na thread original do Slack em vez de criar uma nova mensagem. Isso mantém
as notificações relacionadas agrupadas e reduz o ruído no canal.
Anteriormente consideramos postar edições na mensagem original, mas as
threads preservam melhor a linha do tempo dos eventos e funcionam quando
a mensagem original é mais antiga que a janela de edição do Slack.
Refs SENTRY-1234
PR de Correção de Bug
Tratar resposta nula no endpoint da API de usuário
O endpoint de usuário poderia retornar nulo para contas soft-deleted,
causando crashes no dashboard ao acessar propriedades do usuário. Isso
adiciona uma verificação de nulo e retorna uma resposta 404 apropriada.
Encontrado ao investigar SENTRY-5678.
Fixes SENTRY-5678
PR de Refatoração
Extrair lógica de validação para módulo compartilhado
Move código de validação duplicado dos endpoints de alertas, issues e
projects para uma classe validadora compartilhada. Sem mudança de comportamento.
Isso prepara para adicionar novas regras de validação em SENTRY-9999 sem
duplicar lógica entre endpoints.
Referências de Issues
Referencie issues no corpo do PR:
| Sintaxe | Efeito |
|---|---|
Fixes #1234 |
Fecha issue do GitHub ao fazer merge |
Fixes SENTRY-1234 |
Fecha issue do Sentry |
Refs GH-1234 |
Vincula sem fechar |
Refs LINEAR-ABC-123 |
Vincula issue do Linear |
Diretrizes
- Um PR por funcionalidade/correção - Não agrupe mudanças não relacionadas
- Mantenha PRs revisáveis - PRs menores recebem revisões mais rápidas e melhores
- Explique o por quê - Código mostra o quê; descrição explica por quê
- Marque WIP cedo - Use draft PRs para feedback antecipado