Aprovar / Obter aprovação: o que é, aprovação e code review no Git

O que é aprovação de pull request

A aprovação é uma revisão positiva de um pull request, significando que o revisor verificou o código, não encontrou problemas críticos e considera as alterações prontas para merge. Na interface do GitHub, este é o botão verde «Approve» na página do PR. Após a aprovação, o autor (ou qualquer membro com permissão de escrita) pode realizar o merge.

O processo de aprovação faz parte das Branch Protection Rules. Os proprietários do repositório configuram os requisitos obrigatórios: número mínimo de aprovações (por exemplo, 1 ou 2), quem pode aprovar (proprietários de código, membros da equipe) e se o PR deve ser re-aprovado após alterações (Dismiss stale reviews). Sem a configuração de regras, a aprovação é opcional, mas em equipes profissionais é obrigatória.

O GitLab usa um mecanismo semelhante chamado Approval Rules. No GitLab, você pode configurar quantas aprovações são necessárias de diferentes grupos (por exemplo, 2 de desenvolvedores backend e 1 de DevOps). Após receber todas as aprovações obrigatórias, o PR é automaticamente desbloqueado para merge desde que o pipeline CI/CD esteja verde.

Tipos de revisão: Approve, Request Changes, Comment

GitHub e GitLab têm três tipos de revisão que um revisor pode deixar em um pull request. Cada tipo tem um status e consequências diferentes para o processo de merge. Approve é verde, Request Changes é vermelho, Comment é cinza neutro. A escolha depende da qualidade do código e da prontidão das alterações para aceitação.

Approve — o revisor confirma: o código está escrito corretamente, atende aos padrões, não contém erros óbvios e pode ser mesclado. Approve não significa que o código é perfeito — apenas que é bom o suficiente para produção. Se houver comentários menores (estilo, nomenclatura), eles podem ser deixados como comentários sem bloquear o PR.

Request Changes — o revisor encontra problemas que devem ser corrigidos antes do merge: erros lógicos, vulnerabilidades, violações de arquitetura, falta de testes. Após Request Changes, o PR é bloqueado e é necessária uma nova aprovação do mesmo revisor para desbloqueá-lo (se a opção Dismiss stale reviews estiver ativada em novos commits).

• Approve — código pronto para merge, pode ser mesclado após CI passar.
• Request Changes — correções obrigatórias, PR bloqueado até nova revisão.
• Comment — observação geral ou sugestão sem bloquear o PR.

Configuração de regras de aprovação no repositório

As Branch Protection Rules são o mecanismo do GitHub para controlar a qualidade das mesclagens. Configurado em Settings → Branches para cada branch protegido (main, develop, release/*). Parâmetros principais: número de aprovações obrigatórias, proprietários de código (CODEOWNERS), verificação obrigatória de CI/CD e proibição de push sem PR.

O parâmetro Dismiss stale pull request approvals remove automaticamente as aprovações se um novo commit for adicionado ao PR. Isso garante que os revisores aprovem exatamente a versão do código que será mesclada. Sem essa configuração, o autor poderia adicionar novo código após a aprovação e ele chegaria ao main sem nova verificação.

CODEOWNERS — um arquivo na raiz do repositório que designa responsáveis por diferentes diretórios. Se um PR afeta arquivos pertencentes a um proprietário de código, sua aprovação se torna obrigatória. CODEOWNERS permite distribuir áreas de responsabilidade: desenvolvedores iOS são responsáveis pelos arquivos Swift, DevOps pelas configurações Docker, testadores pelos cenários de teste.

# Arquivo CODEOWNERS de exemplo na raiz do repositório

# Desenvolvedores iOS são donos do código Swift
*.swift @team/ios-developers

# DevOps é dono da configuração de CI/CD
.github/workflows/* @devops-team

# Engenheiros de QA revisam os testes
**/tests/* @qa-engineers

# Proprietários padrão para todo o resto
* @tech-leads

Code review antes da aprovação: o que verificar

O code review antes da aprovação é uma verificação sistemática do código, não uma olhada rápida no diff. Uma revisão de qualidade inclui verificação de arquitetura, lógica, estilo, testes e segurança. Sem essa verificação, a aprovação se torna uma formalidade em vez de uma ferramenta de controle de qualidade.

O que é verificado primeiro: a lógica das alterações — se o código resolve a tarefa, se há efeitos colaterais, se o tratamento de casos limite está correto. Testes — se os novos testes cobrem todos os cenários, se os testes existentes passam após as alterações. Segurança — se há injeções SQL, XSS, vazamentos de dados sensíveis.

O que não deve ser objeto de revisão: estilo de formatação (para isso existem linters e formatadores), decisões arquiteturais tomadas previamente (são discutidas antes de escrever o código). Se uma revisão exceder 400 linhas ou levar mais de uma hora, é sinal de que a tarefa é muito grande e requer decomposição. Melhores práticas de revisão — porções de 200–400 linhas em até 24 horas após a criação do PR.

• Lógica — correção da solução, tratamento de erros, casos limite.
• Testes — cobertura de novos cenários, testes existentes passando, sem testes flaky.
• Segurança — sem injeções, escape de saída, controle de acesso a dados.
• Desempenho — eficiência de algoritmos, consultas excessivas, vazamentos de memória.
• Documentação — se a documentação está atualizada, se os comentários em seções complexas são claros.

Fluxo de trabalho com aprovação em equipe

Um fluxo de trabalho típico com aprovação em uma equipe de 5–10 desenvolvedores é assim: um desenvolvedor cria um PR, designa revisores (geralmente 1–2 pessoas da equipe ou proprietários de código), CI/CD executa verificações automáticas. Após receber todas as aprovações obrigatórias e um CI verde, o autor realiza o merge. O tempo desde a criação do PR até o merge varia de 2 horas a 2 dias, dependendo da complexidade.

GitHub Actions permite automatizar o merge após a aprovação. Se as regras de branch estão configuradas, o GitHub bloqueia o merge até que todas as condições sejam atendidas. Algumas equipes usam bors-ng ou Mergify — bots que mesclam automaticamente os PRs após receber todas as aprovações e passar no CI. Isso acelera o processo e elimina o fator humano nas mesclagens.

Uma abordagem moderna é o trunk-based development com branches de curta duração. Neste fluxo, a aprovação deve ser obtida em poucas horas, caso contrário a tarefa é considerada obsoleta e requer ressincronização com main. Equipes com alta cultura de revisão visam um tempo de aprovação de não mais que 4 horas úteis.

Erros na aprovação e como evitá-los

O erro mais comum é a aprovação formal sem revisão real do código. Quando o PR é grande ou o prazo está próximo, o revisor pode clicar em Approve sem examinar as alterações. Isso desvaloriza todo o processo de code review. Solução: estabelecer um limite no tamanho do PR (não mais de 400 linhas) e usar ferramentas de análise de código (SonarQube, CodeClimate) para verificação automática.

O segundo erro é a aprovação excessivamente rigorosa. Esperar código perfeito bloqueia o desenvolvimento. Os revisores às vezes exigem corrigir comentários estilísticos que não afetam a qualidade. Solução: dividir claramente entre comentários obrigatórios (bloqueantes) e sugestões opcionais (comentários). O GitHub permite especificar explicitamente se um comentário é bloqueante.

O terceiro erro é a aprovação sem verificar CI/CD. Mesmo que o código pareça correto, ele pode não compilar ou falhar nos testes. As Branch Protection configuradas bloqueiam automaticamente o merge com CI vermelho, mas algumas equipes desativam essa proteção por rapidez. Solução: sempre verificar o status do CI antes de aprovar e nunca aprovar um PR com pipeline vermelho.

• Aprovação formal — ausência de revisão real do código. Solução: limite de 400 linhas por PR.
• Rigor excessivo — bloqueio por comentários estilísticos. Solução: dividir em bloqueantes e opcionais.
• Ignorar CI — aprovação com pipeline vermelho. Solução: sempre verificar o status dos testes.
• Indicação do autor — aprovação pelo autor do PR. Solução: configurar Branch Protection contra o autor.