Branches e Pull Requests

Os branches existem porque o trabalho de engenharia real não acontece em uma única sequência linear. Em qualquer momento, uma equipe de cinco pessoas pode ter três funcionalidades em andamento, uma correção de bug em revisão e uma mudança de infraestrutura aguardando uma janela de deploy. Sem branches, todo esse trabalho colidiria em um único espaço de trabalho compartilhado — funcionalidades incompletas quebrando umas às outras, uma correção de bug sendo enviada acidentalmente com uma funcionalidade incompleta, mudanças de infraestrutura se entrelaçando com código de produto.

Um branch dá a cada fluxo de trabalho seu próprio contexto isolado. Você pode quebrar coisas, experimentar, refatorar agressivamente — e nada disso afeta seus colegas de equipe até que você escolha explicitamente fazer o merge. Esse isolamento é o que torna o trabalho paralelo possível sem sobrecarga constante de coordenação.

Mas o isolamento é apenas metade do valor. Os branches também reduzem o custo da experimentação. Quer testar um algoritmo diferente? Crie um branch, faça um protótipo, meça o desempenho. Se for mais rápido, faça o merge. Se não for, delete o branch. Custo total: zero danos à base de código compartilhada, zero ruído no histórico de commits, zero rollbacks necessários. Equipes que criam branches livremente experimentam mais abordagens e encontram soluções melhores. Equipes que tratam a criação de branches como algo pesado (ou a ignoram completamente fazendo commits direto na main) ou experimentam menos ou experimentam perigosamente.

Um pull request é uma proposta: "Aqui está o que mudei, aqui está o porquê, e gostaria que alguém olhasse antes de fazer o merge." Isso parece simples, mas representa uma mudança fundamental de controle de qualidade implícito para explícito.

Sem PRs, a revisão de código é opcional, ad-hoc e inconsistente. Talvez alguém olhe seu código antes de ele ser enviado, talvez não. Talvez olhem parte dele. Talvez olhem depois que já está em produção. Os PRs tornam a revisão uma porta — o código não chega à main até que pelo menos outro engenheiro o tenha lido, entendido a intenção e aprovado a abordagem.

Isso não é sobre pegar bugs (embora faça isso). É sobre responsabilidade compartilhada. Quando um PR é revisado e aprovado, a mudança não é mais "o código da Sarah" — é o código da equipe. O revisor está dizendo "Eu entendo isso, concordo com a abordagem e me sinto confortável mantendo isso." Essa responsabilidade distribuída significa que nenhum engenheiro se torna um gargalo ou um ponto único de falha.

Os PRs também criam um registro de decisões. A descrição explica o porquê, o diff mostra o quê, e os comentários da revisão capturam as compensações consideradas. Três meses depois, quando alguém pergunta "por que construímos dessa forma?", o PR tem a resposta — incluindo as alternativas que foram discutidas e rejeitadas.

A revisão de código dá errado quando se torna um ritual de controle de acesso — um engenheiro sênior bloqueando merges com detalhes de estilo enquanto a equipe espera. Isso não é revisão; é um gargalo disfarçado de qualidade.

Uma boa revisão de código é uma conversa entre pares. O trabalho do revisor não é provar que sabe mais — é perguntar "entendi sua intenção?" e "você considerou este caso extremo?" Os melhores comentários de revisão são perguntas, não diretivas. "O que acontece se esta lista estiver vazia?" ensina mais do que "Adicione uma verificação de nulo aqui."

Três princípios que mantêm a revisão produtiva:

• Revise a abordagem, não a sintaxe. Linters capturam formatação. Humanos devem focar em lógica, arquitetura e nomenclatura — coisas que máquinas não conseguem avaliar.
• Responda em horas, não em dias. Um PR esperando revisão por 72 horas é trabalho bloqueado. Se você não pode revisar hoje, diga — deixe outra pessoa assumir.
• Distinga bloqueante de não-bloqueante. "Isso vai quebrar em produção" é bloqueante. "Eu nomearia essa variável de forma diferente" é uma sugestão. Misture-os e toda revisão parece uma briga.

A cultura de revisão também é uma das ferramentas de onboarding mais eficazes que uma equipe tem. Um novo engenheiro lendo revisões de PR aprende os padrões, preferências e erros passados da equipe mais rápido do que qualquer documentação poderia ensinar. O arquivo de revisões é um guia de estilo vivo.