Campeão de Merge de PR

Visão Geral

Um manual sistemático para preparar, revisar e documentar pull requests para garantir que sejam de alta qualidade, livres de descuidos comuns e otimizados para aprovação e merge instantâneos pelos mantenedores.

Quando Usar Esta Habilidade

• Use ao se preparar para abrir um novo pull request no GitHub ou em qualquer plataforma de hospedagem Git.
• Use ao auditar um branch de feature ou correção de bug para limpeza e consistência do código.
• Use ao tentar minimizar ciclos de revisão e acelerar a integração de suas alterações.

Como Funciona

Etapa 1: Limpeza e Rebase Pré-Voo

Antes de apresentar seu código aos revisores, limpe qualquer ruído do espaço de trabalho e garanta que seu branch esteja atualizado:

1. Faça o rebase do seu branch de feature sobre o branch alvo mais recente (por exemplo, main ou master) para resolver conflitos precocemente.
2. Limpe arquivos não rastreados, temporários ou de swap do seu repositório.
3. Execute linters, formatadores e compiladores locais para garantir que não existam erros de estilo ou sintaxe.

Etapa 2: Auto-Revisão Crítica

Revise seu próprio diff linha por linha como se fosse o revisor. Procure por:

1. Declarações de depuração deixadas para trás (por exemplo, console.log, print, breakpoints ou flags de depuração personalizadas).
2. Alterações desnecessárias, diffs apenas de espaço em branco ou blocos de código comentados.
3. Comentários de TODO incompletos que devem ser resolvidos ou transformados em issues rastreáveis.
4. Correção do tratamento de erros e casos extremos.

Etapa 3: Verificação Local e Suíte de Testes

Verifique se todas as alterações funcionam como esperado:

1. Execute a suíte de testes automatizados do projeto localmente para verificar se nenhuma regressão foi introduzida.
2. Verifique a cobertura de testes para quaisquer novos blocos de código que você adicionou.
3. Teste manualmente os caminhos críticos e os casos extremos da sua feature ou correção de bug.

Etapa 4: Elaboração da Descrição do Pull Request

Escreva uma descrição de PR estruturada e de alto sinal. Uma ótima descrição conta a história das alterações:

1. Resumo: Uma explicação concisa das alterações.
2. Contexto / Por quê: Por que essa alteração é necessária e qual problema ela resolve.
3. Verificação: Detalhes explícitos sobre como você a testou (comandos de teste, capturas de tela ou reprodução passo a passo).
4. Checklist: Conforme as diretrizes de contribuição do repositório e os requisitos da checklist.

Exemplos

Exemplo 1: Criando uma Descrição de PR Limpa

# Pull Request: Implement Rate Limiting on Authentication Endpoint

## Summary
Introduces an IP-based rate limiter on the `/api/v1/auth/login` endpoint using Redis to prevent brute-force attacks.

## Why
We identified a high volume of login attempts targeting single accounts. This rate limiting window slows down attackers while keeping the system responsive for genuine users.

## Verification
- Ran unit tests: `npm run test tests/auth.test.js` (all green)
- Manually verified using Postman: sending 15 requests in under 60 seconds returns `429 Too Many Requests`.

## Checklist
- [x] Code follows the style guide
- [x] Unit tests added/updated
- [x] Documentation updated

Exemplo 2: Comandos de Limpeza para Auto-Revisão

Antes de commitar, execute estes comandos para inspecionar o diff em busca de adições acidentais:

# Check the names of files changed to ensure no unwanted files are staged
git status --porcelain

# Review the actual diff for any leftover print statements or debuggers
git diff | grep -E "(console\.log|debugger|print\(|var_dump|binding\.pry)"

Melhores Práticas

• ✅ Mantenha os PRs Pequenos e Focados: Um PR com menos de 200 linhas de alterações é revisado e merged significativamente mais rápido do que um grande.
• ✅ Faça uma Auto-Revisão primeiro: Encontrar seus próprios bugs e problemas de formatação primeiro constrói confiança com os mantenedores.
• ✅ Respeite as Diretrizes do Repositório: Verifique os CONTRIBUTING.md do projeto e os templates de pull request, e adira a eles estritamente.
• ❌ Não Agrupe Alterações Não Relacionadas: Evite inserir refatorações ou correções de bugs não relacionadas em um PR de feature. Crie PRs separados em vez disso.
• ❌ Não Ignore Falhas de CI: Sempre corrija testes, linters ou verificações de segurança que falharem no seu branch antes de solicitar uma revisão.

Limitações

• Esta habilidade não substitui a validação de CI/CD específica do projeto, testes automatizados ou revisões por especialistas do domínio.
• Assume um ambiente Git e GitHub padrão, embora os princípios centrais se apliquem a GitLab, Bitbucket e outras plataformas.

Armadilhas Comuns

• Problema: Um PR fica aberto por muito tempo devido a comentários menores de formatação ou estilo.

…