Por Que `main` É Sagrado

"Main sempre verde" significa uma coisa: a qualquer momento, o branch main pode ser implantado em produção. Não "funciona na maioria das vezes", não "funciona se você souber quais commits pular" — implantável. Agora mesmo. Sem intervenção manual.

Esse é um padrão mais alto do que a maioria das equipes percebe. Significa que cada commit no main passou por testes automatizados, foi revisado por um humano e não depende de trabalho incompleto de outro branch. Significa que você pode fazer deploy na sexta-feira às 16h sem ansiedade, porque o main não é um trabalho em andamento — é o produto finalizado em cada commit.

O mecanismo que garante isso é a integração contínua (CI). Cada PR executa a suíte de testes, o linter e o verificador de tipos antes de poder fazer merge. Se alguma verificação falhar, o PR é bloqueado. O desenvolvedor corrige o problema no seu branch — não no main, não depois do merge, não "mais tarde". A CI é o guardião que garante que o main nunca se degrade.

Equipes sem essa disciplina regularmente se encontram em um estado onde o main está quebrado e ninguém sabe qual dos últimos cinco merges causou isso. Nesse ponto, todos na equipe estão bloqueados — não podem puxar código novo, não podem iniciar novos branches a partir de um estado funcional e não podem fazer deploy. O custo de um main vermelho não é problema de um desenvolvedor. É problema de toda a equipe, se agravando a cada minuto que permanece quebrado.

Regras de proteção de branch são a aplicação automatizada de "main sempre verde". Todas as principais plataformas de hospedagem Git — GitHub, GitLab, Bitbucket — as suportam, e elas devem ser configuradas no primeiro dia de qualquer projeto sério.

As três regras que mais importam:

• Revisões de PR obrigatórias. Nenhum push direto para o main. Cada mudança passa por um PR e pelo menos uma aprovação. Isso captura o impulso "vou só fazer push dessa correção rápida" que é responsável por uma parcela desproporcional de incidentes em produção.
• Verificações de status obrigatórias. A CI deve passar antes do merge. Testes, linting, verificação de tipos — o que quer que seu pipeline execute. Uma verificação falhando bloqueia o botão de merge. Sem substituições, sem "vou corrigir no próximo commit".
• Histórico linear. Exigir que os branches estejam atualizados com o main antes do merge (rebase ou fila de merge). Isso evita a situação onde dois PRs passam na CI individualmente mas quebram quando combinados — porque cada PR é testado contra o estado atual do main, não um snapshot desatualizado.

Algumas equipes resistem às regras de proteção porque parecem atrito. Elas são atrito — atrito intencional que previne a classe mais cara de erros. Configurar essas regras leva cinco minutos. Recuperar-se de um force-push que sobrescreve o trabalho de um colega leva horas, mais o dano à confiança. A matemática não é difícil.

Quando um deploy quebra a produção, os desenvolvedores enfrentam uma escolha: corrigir para frente ou reverter. O instinto é quase sempre corrigir para frente — encontrar o bug, escrever um patch, fazer push. Mas esse instinto está errado sob pressão.

Um revert é um único comando que desfaz um commit conhecido de forma limpa:

git revert abc123f
# Creates a new commit that undoes abc123f
# Main is green again in minutes

A alternativa de correção em pânico se parece com isso: um desenvolvedor curvado sobre o teclado às 23h, escrevendo código novo sob pressão, pulando testes porque "é só uma correção de uma linha", fazendo push direto para o main porque "não temos tempo para um PR". Essa correção de uma linha introduz um segundo bug 40% das vezes, porque código escrito sob adrenalina é código escrito sem contexto completo.

A regra é simples: reverta primeiro, corrija depois. Deixe o main verde novamente imediatamente — isso desbloqueia toda a equipe e estanca o sangramento. Então, com a pressão aliviada, escreva uma correção adequada em um branch com testes, revisão e CI. A correção é enviada uma hora ou um dia depois, mas é enviada corretamente.

Reverts parecem admitir falha. Não são. São o caminho mais rápido de volta a um estado funcional, e deixam o commit original no histórico como documentação do que deu errado. Uma equipe que reverte rapidamente é uma equipe que faz deploy com confiança, porque o custo de um deploy ruim é minutos de inatividade em vez de horas de combate a incêndios.