“Na minha máquina funciona” não escala: O segredo da padronização e Git em grandes empresas

Em projetos pessoais, startups em início de jornada ou pequenas agências digitais, cada um coda do seu jeito. Subir pra produção via FTP, corrigir à quente via SSH, enviar por e-mail para os colegas os arquivos modificados, fazer backup com *.bkp direto no servidor… Você nunca deve ter visto essa bagunça na vida real, não é mesmo? Sim, contém ironia. Depois de anos de experiência e busca por boas práticas, atualmente eu não consigo fazer uma landing page simples em HTML/CSS/JS sem criar um repositório Git pro projeto, mesmo trabalhando sozinho. Acima de tudo eu respeito o meu tempo e o do cliente, e retrabalho me desanima bastante.

O que acontece quando você tem 500 desenvolvedores no mesmo projeto, com 30 microsserviços, cada um com seu repositório Git? Ou apenas um monolito, 10 desenvolvedores, porém com um milhão de acessos por dia?

Pode não ser ainda o caso mas, se der tudo certo, a startup vai começar a escalar, o projeto vai crescer exponencialmente, após a rodada seed, de 3 devs, em um mês são 80 devs.

Então temos que começar a pensar como gente grande. Não é apenas conhecimento – é aculturamento, metodologia e liderança técnica.

Quando passei a trabalhar em grandes empresas tive o impacto inicial e a curva de aprendizado, e participei da elaboração de planos para implementar rotinas em ambientes de projetos enormes com grande número de pessoas envolvidas.

Como conteúdo sobre esses aspectos é meio raro – fala-se muito sobre especificidades, mas não sobre o todo – resolvi escrever uma série de artigos abordando o ambiente, a metodologia e as culturas de desenvolvimento em ambientes grandes, muito grandes. Não vou entrar nos detalhes de implantação, mas nos aspectos que importam em ambientes ágeis, críticos e com muita gente envolvida.

🌿 Git Flow vs. Trunk Based: O Capacidor de Fluxo

Git não deveria estar como requisito nas vagas de recrutamento de desenvolvedores, deveria ser usado por alunos do primário para realizarem trabalhos em grupo com arquivos *.txt. Ponto.

Quando falamos de versionamento, existem dois grandes modelos de governança consolidados e entender a diferença entre eles é crucial para a saúde do time.

1. Git Flow: O Clássico Robusto

Este ainda é um padrão ouro, utilizado em grandes empresas e grandes projetos. Ele organiza o caos através de uma estrutura rígida de branches:

• Master/Main: A verdade absoluta. O que está em produção.
• Develop: O ambiente de integração onde o trabalho do dia a dia se encontra.
• Feature Branches: Onde cada dev trabalha isoladamente (feature/novo-login).
• Release & Hotfix: Branches temporárias para preparar uma versão ou corrigir um bug crítico.

Ele ainda funciona? Com certeza. O Git Flow é excelente para cenários onde você precisa de um controle rigoroso de versões. O segredo para o Git Flow funcionar em grandes empresas sem virar um pesadelo é a disciplina: branches de feature não podem durar semanas. Se a equipe mantém ciclos curtos e faz o merge para a develop frequentemente, o Git Flow oferece uma organização visual e semântica impecável, evitando conflitos demasiados.

Branches e entregas rápidas devem estar alinhadas com as sprints ou movimentações no Kanban, e pra isso, é necessário um alinhamento estrito com product owner e agilista, componentizando as pequenas entregas e garantindo o mínimo de impacto e conflitos. Ou seja, é necessária uma cultura de desenvolvimento e entregas.

Geralmente o Git Flow é definido pelas lideranças técnicas, são semelhantes tendo variações de acordo com os ambientes existentes (a empresa pode ter um pré-prod ou não).

2. Trunk Based Development (TBD): A Velocidade das Big Techs

É aqui que empresas como Google, Amazon e Meta jogam, além de muitas empresas e serviços no Brasil. O foco muda do “controle de versão” para a “integração contínua”.

No TBD, a burocracia de branches diminui drasticamente:

• Conceito: Desenvolvedores commitam diretamente na main ou usam branches de vida curtíssima (que duram horas, não dias).
• A Lógica: Em vez de esperar uma semana para integrar o código e descobrir conflitos gigantescos, integra-se “pacotinhos” de código várias vezes ao dia.
• Vantagem: O código está sempre “fresco”. O Merge Hell (inferno da resolução de conflitos) (quase) desaparece porque as diferenças entre a minha máquina e a main são sempre pequenas.

⚖️ Qual escolher?

A tendência do mercado moderno, focado em SaaS e Web, é migrar para o Trunk Based. Ele força a verdadeira Integração Contínua (CI). Se o código dói para integrar, a solução é integrar com mais frequência, não com menos.

💡 Observação

Para adotar o Trunk Based (ou mesmo um Git Flow acelerado) sem quebrar a produção toda terça-feira, a sua empresa precisa de Maturidade de Engenharia. Isso significa duas coisas obrigatórias:

1. Testes Automatizados Robustos: Desde scripts de pré-commit até a esteira de CI tem que garantir que o commit seja seguro.
2. Feature Flags: A capacidade de subir código para produção “desligado”.

Ou seja, TBD também necessita de uma cultura – essa mais desvinculada das regras de negócio mas no relacionamento entre os desenvolvedores.

⚠️ Spoiler: Segurem a ansiedade: vou explicar exatamente como usar Feature Flags para desacoplar o Deploy da Release num artigo futuro desta série.

🛡️ O Guardião da Qualidade Local: Git Pre-commit Hooks

Se o versionamento organiza o fluxo, os Hooks garantem a higiene. Ninguém quer ser aquele colega “chato” no Code Review que reprova um Pull Request (PR) gigante só porque sobrou um espaço em branco no final da linha ou a indentação está errada.

Isso gera atrito desnecessário entre desenvolvedores e desperdiça tempo, cognição, foco e energia. A solução em grandes empresas é simples: automatizar a “chateação” antes mesmo dela sair da máquina do dev. Coisas que podem ser automatizadas, devem ser automatizadas, e não devem ficar à cargo de foco e esforço humano.

O que são: Basicamente, são scripts que interceptam o comando git commit. Eles funcionam como um porteiro rigoroso: se as regras pré-definidas não forem cumpridas, o commit é bloqueado instantaneamente. O código nem chega a ser criado no histórico local.

O que devemos validar aqui (Checklist Básico):

• 🔐 Segurança (O Crítico): O maior pesadelo de uma empresa é vazar uma credencial. Ferramentas como git-secrets, trufflehog ou gitleaks varrem o código staged. Se detectarem padrões de chaves da AWS, Tokens ou senhas hardcoded, o commit é barrado. Isso é DevSecOps raiz.
• 🧹 Linting e “Sanidade”: O código que sobe já deve estar limpo. O hook roda verificações rápidas de sintaxe (lint). Isso garante que o Code Review humano foque no que importa: arquitetura, lógica de negócio e performance, e não em discutir se falta um ponto e vírgula.
• 📝 Padronização de Mensagens: Em grandes times, rastreabilidade é lei. Hooks (como o commitlint) forçam o padrão Conventional Commits (ex: feat: adiciona login, fix: corrige erro XPTO). Isso não é preciosismo; é o que permite gerar Changelogs automáticos e versionamento semântico lá na frente. 💡 Por experiência, além das convenções de commits, recomendo não permitir acentuação e manter caixa baixa para todos textos de commit – me agradeçam no futuro.

As Ferramentas de Mercado: Ninguém mais escreve scripts complexos em Bash na mão para isso.

• No ecossistema JavaScript/Node, o Husky é o padrão, fácil de configurar no package.json.
• Para ambientes Python e várias outras linguagens (Go, Terraform, Java…), o framework pre-commit é a ferramenta dominante pela sua extensibilidade.

O Ganho Cultural: Implementar hooks tira o peso da “fiscalização” das costas do Tech Lead e passa para a máquina. O feedback é imediato para o desenvolvedor, que corrige o erro em segundos, sem a vergonha de ter um código rejeitado publicamente no PR.

🎨 Linting e Formatação: O Código sem “Sotaque”

Há uma analogia com o jornalismo que se aplica perfeitamente à engenharia de software: ler o código de uma grande empresa deve ser como ler um jornal.

Quando você abre um grande portal de notícias, você não sabe qual jornalista escreveu qual matéria apenas olhando para a formatação do texto. O estilo, a estrutura e a pontuação são uniformes. No código, o objetivo é o mesmo. Se eu abro um arquivo e consigo dizer “Ah, isso aqui foi o João que escreveu” apenas porque ele usa 2 espaços de indentação e variáveis com nomes estranhos, temos um problema de propriedade coletiva do código.

Para que um time de 50, 100 ou 1000 pessoas trabalhe no mesmo repositório, o código não pode ter “sotaque”. Ele precisa ser impessoal e padronizado. Para isso, usamos duas ferramentas distintas que muitas vezes são confundidas:

1. Linter: O Fiscal da Lógica e Qualidade

O Linter não está preocupado se o código é “bonito”, mas sim se ele é seguro e correto.

• O que faz: Ele analisa estaticamente o código procurando “code smells” (cheiro de código ruim), variáveis não utilizadas, erros de tipagem ou complexidade ciclomática excessiva.
• Ferramentas: O onipresente ESLint (JavaScript/TS), SonarLint (Multilinguagem), Pylint (Python), golang-ci-lint (GoLang), etc, etc.
• Valor: Ele ensina o desenvolvedor enquanto ele digita, prevenindo bugs lógicos bobos antes mesmo de rodar a aplicação.

2. Formatter: O Estilista Automático

Aqui entra a estética pura. O Formatter reescreve o seu código para garantir que a indentação, quebra de linhas, uso de aspas e ponto e vírgula sigam uma regra rígida.

• O que faz: Você escreve de qualquer jeito, roda a ferramenta e o código é reformatado magicamente para o padrão do projeto.
• Ferramentas: Prettier (o rei do ecossistema Web – PHP, JS, …), Black (o formatador “intransigente” do Python), gofmt, etc.
• Filosofia: Ferramentas como o Black e o Prettier são “opinionated” (opinativas). Elas tiram a decisão do desenvolvedor. Não há discussão se é melhor usar aspas simples ou duplas; a ferramenta decide e ponto final.

🧠 O Benefício Real: Redução da Carga Cognitiva

Por que grandes empresas investem tempo configurando isso? A resposta está na Carga Cognitiva e na eficiência do Code Review.

Ler código é muito mais difícil do que escrever. Quando o código está visualmente padronizado, o cérebro do revisor “pula” a análise visual e foca 100% na lógica de negócio e na arquitetura.

Sem essas ferramentas, os Code Reviews viram discussões triviais sobre “falta um espaço aqui” ou “quebra essa linha ali”. Com Linters e Formatters, essas discussões morrem. O Review foca no que importa: “Essa solução escala?”, “Isso vai travar o banco de dados?”.

É mais uma mudança cultural: deixamos a máquina cuidar da forma, para que os engenheiros possam focar no conteúdo.

🏁 Resumo da Ópera: A Cultura começa no Local

A grande lição desta primeira etapa é: qualidade e padronização não são “acessórios”, são requisitos de sobrevivência em escala.

Vimos que não importa se você escolhe a robustez do Git Flow ou a velocidade do Trunk Based Development; ambos exigem disciplina e alinhamento cultural. Mas, para que qualquer fluxo funcione, precisamos remover a fricção cognitiva.

Ao configurar Pre-commit Hooks e padronizar o código com Linters e Formatters, transformamos regras abstratas em travas automatizadas. Isso garante que, se o código saiu da máquina do desenvolvedor, ele já está “redondo”, seguro e legível. A máquina cuida da burocracia, o humano cuida da inteligência.

Fluxo Local Ideal:

1. Dev escreve código 💻
2. git commit 🛑
3. Bloqueio: Pre-commit Hooks rodam (Lint, Testes Rápidos, Check de Senhas) ⚙️
4. Se passar ✅ -> Código vai para o Git.

📢 Agora me conta: Na sua empresa atual, vocês adotam Git Flow ou o Trunk Based Development? A automação local já existe ou o Code Review ainda discute espaço em branco?´

👇 Deixem a sua experiência nos comentários!

⏭️ No próximo artigo: O código já saiu da nossa máquina. E agora? Vamos entrar no mundo da Automação Centralizada. Preparem-se para falar sobre a mágica (e os perigos) das Pipelines de CI/CD e GitHub/GitLab Actions. Até lá!

📈 Sua Startup está nesse momento, de crescimento exponencial, buscando sustentabilidade para a tecnologia e os negócios? Me chama, vamos conversar!