Você mantém um projeto open source e sente que a enxurrada de pull requests (PRs) está sufocando seu tempo livre? O GitHub ouviu esse coro de reclamações — que só cresce com a chegada massiva de contribuições geradas por IA — e acaba de lançar o limite de pull requests por usuário. A novidade, anunciada nesta terça-feira (18), quer diminuir drasticamente o ruído de mudanças mal acabadas e recuperar o prazer de revisar código.
Por que essa mudança era urgente?
Em janeiro de 2023, a comunidade mesclava cerca de 25 milhões de PRs por mês. Hoje, esse número ultrapassa 90 milhões — um aumento de 3,6 vezes em pouco mais de três anos. A facilidade em “abrir PR” nunca foi tão grande, principalmente com ferramentas de IA como o Copilot gerando patches em segundos. O problema é que revisar ainda consome o mesmo tempo humano de sempre.
Resultado: contribuições excelentes e “rascunhos” chegam na mesma fila, tornando difícil enxergar o que realmente merece atenção. O novo limite vem para reorganizar esse funil.
Como funciona o limite de pull requests
A partir de agora, mantenedores podem definir um número máximo de PRs abertos por contribuidores sem permissão de escrita. Ao atingir o teto, o usuário precisa fechar ou mesclar uma das solicitações antes de abrir outra. Confira os detalhes:
- PRs criados por IA (Copilot ou outras) contam no limite.
- Rascunhos (draft pull requests) não entram na conta.
- Existe uma lista de bypass para colaboradores de confiança: eles podem superar o teto sem receber acesso total ao repositório.
Diferente dos atuais interaction limits, que são “resfriamentos” temporários, essa nova barreira é persistente e configurável, dando ao maintainer o controle que faltava.
O que muda para quem contribui
Se antes era fácil “atirar” dez commitzinhos e esperar a triagem, agora cada PR aberto custa. O contribuinte precisa escolher melhor o que vale seu slot, revisar o código antes de submeter e agrupar pequenas correções em uma única solicitação. A filtragem inicial, portanto, acontece antes de chegar às mãos do maintainer — e o trabalho de qualidade salta aos olhos.
Repercussão inicial
Projetos com grandes comunidades comemoraram:
- Nicholas Tindle (AutoGPT): “Saber que ninguém vai abrir dez PRs ruins de uma vez faz a revisão voltar a ser prazerosa.”
- Mike McQuaid (Homebrew): “Usuários entusiasmados mandavam várias mudanças quase idênticas; a IA acelerou isso. O limite nos devolve o controle.”
- Vincent Koc (OpenClaw): “Mantínhamos bots caseiros contra spam. É ótimo ver o GitHub oferecendo uma solução oficial.”
Próximas etapas já no radar do GitHub
A empresa deixou claro que esse é só o começo de um pacote maior de ferramentas para moderar contribuições:
Imagem: Internet
- Arquivar pull requests (em breve): esconder PRs de baixa qualidade sem deletá-los, atendendo requisitos legais ou de compliance.
- Limites de issues (em desenvolvimento): o mesmo cap de PRs será aplicado a abertura de issues.
- Sinais de confiança automáticos: liberar o bypass baseado em fatos, como PRs aprovados anteriormente, idade da conta ou pertencer a uma organização.
- Controles cross-repository: detectar usuários que “espalham” PRs em centenas de repositórios simultaneamente.
Qual o impacto prático para você (manter ou contribuir)
Para mantenedores, a novidade significa menos fadiga e backlog mais limpo, liberando energia para revisar as mudanças que realmente importam — como otimizações de desempenho ou novas features que podem, por exemplo, exigir hardware mais potente em servidores.
Para contribuidores, a lição é clara: revise seu código, agrupe commits e descreva bem suas motivações. A qualidade sobe, e suas chances de ver o PR aprovado aumentam.
E quando a revisão precisa ser rápida — sobretudo em times que testam software em máquinas locais — investir num bom teclado mecânico low-profile ou em um mouse ergonômico de alta precisão (veja nossas sugestões na Amazon) pode acelerar não só a digitação de código, mas também o processo de merge e squash de commits. Pequenos upgrades de hardware fazem diferença no dia a dia do desenvolvedor.
Como habilitar o limite no seu repositório
A opção já aparece em Settings › General › Pull request limits. Defina o número ideal — o GitHub sugere começar baixo (2 ou 3) em projetos muito movimentados — e teste por uma semana. Ajuste conforme o feedback da comunidade.
No fim, a mensagem do GitHub é simples: “Nos vemos na fila de pull requests.” Agora, com bem menos barulho.
Com informações de GitHub Blog
