GitHub como Conduto: da IA ao Repositório à Produção

Engenheiros gastam inúmeras horas debatendo qual modelo de IA gera melhor código, qual editor tem o melhor autocompletar, qual framework de UI é mais elegante. Esses debates são legítimos, mas obscurecem uma verdade incoveniente: nenhum deles importa se você não consegue colocar o código em produção de forma segura, rápida e reversível.

O conduto — o caminho do editor à produção — é onde a maior parte das equipes perde velocidade. Pipelines artesanais de Jenkins, scripts rsync frangos, servidores Heroku abandonados, AWS CodePipelines com 17 etapas opacas. Cada uma dessas escolhas adiciona fricção e oportunidade de erro. O insight da Pillar é que você pode terceirizar essa camada inteiramente: GitHub para versionamento e gatilhos, Cloudflare para build e distribuição. Você não precisa pensar nisso, e isso é precisamente o ponto.

Quando o conduto é trivial, você pode iterar com a velocidade de quem trabalha apenas no repositório local. Quando o conduto é complexo, você constrói corretamente uma vez por semana — e isso não é suficiente em um mundo onde agentes de IA podem produzir dezenas de iteráveis por dia.

Um repositório GitHub serve a três propósitos simultaneamente: arquivo (histórico imutável), backup (cópia fora da sua máquina) e gatilho (sinal para sistemas externos como Cloudflare). A maioria dos construtores subutiliza dois dos três.

Como arquivo, cada commit registra não apenas o que mudou, mas quem fez a alteração, quando e por quê. Quando você usa Claude Code para gerar código, recomendamos taggear isso explicitamente na mensagem — algo como feat: adiciona validação de formulário (gerado por Claude Code). Seis meses depois, quando você estiver investigando por que um bloco de código existe, esse contexto é ouro.

Como gatilho, é aqui que o GitHub se transforma em mais do que armazenamento. Conecte seu repositório a Cloudflare Pages uma única vez na interface da Cloudflare. A partir daí, cada push para main dispara um build de produção; cada push para uma branch de feature dispara um deploy de preview com URL única. Você não configura nada além disso. Sem YAML. Sem webhooks manuais. Sem chave SSH copiada para servidores.

A internet está cheia de artigos sobre GitFlow, GitHub Flow, trunk-based development, release branches. A maioria desses esquemas foi projetada para times de 50+ pessoas com ciclos de release semanais ou mensais. Eles são desnecessariamente complexos para construtores modernos.

A estratégia que recomendamos: main é produção. Cada commit que chega lá vai para o mundo. Trabalho em andamento acontece em branches de feature (feat/nova-pagina-precos, fix/cabecalho-mobile) que recebem deploys de preview automáticos. Você revisa o preview, faz merge via PR (ou direto no caso de mudanças triviais) e o deploy para produção ocorre em segundos.

Quando exigir revisão de PR mesmo trabalhando sozinho? Três casos: (1) mudanças de schema de banco de dados — sempre, sem exceção; (2) código de cobrança ou que toca em Stripe, Payment Links ou faturamento; (3) qualquer rota com dados sensíveis (autenticação, dados pessoais, admin). Para mudanças de copy, ajustes de CSS ou novas páginas estáticas, pular o PR é perfeitamente seguro.

Existe uma única regra de higiene de commits que você não pode quebrar: nunca, jamais, em hipótese alguma, faça commit de segredos. Chaves de API, tokens de deploy, senhas de banco, secrets de webhook — nada disso entra no Git. Use .gitignore agressivamente, configure .env.example com placeholders, e prefira a arquitetura de zero-secret descrita em Zero-Secret Architecture.

Por que isso importa tanto? Porque o Git tem memória. Mesmo se você deletar um arquivo e fizer commit, o segredo permanece no histórico. Reescrever histórico público é doloroso e não garante limpeza. Scrapers automatizados monitoram pushes para o GitHub procurando por chaves expostas dentro de segundos — sim, segundos, não horas.

Além disso, adote mensagens de commit semânticas: feat: para novidades, fix: para correções, docs: para documentação, refactor: para mudanças estruturais. Esse padrão não é vaidade — é um sinal compressível que você (ou seu agente de IA do futuro) pode usar para entender rapidamente o que aconteceu em uma janela de tempo.