Git para dados: padrões de branch, PR e code review para times de Analytics
Times de dados costumam começar “sem querer” no Git. Primeiro, surgem algumas queries para responder perguntas de negócio. Depois, vem um modelo dbt para padronizar métricas. Em seguida, aparece um DAG no Airflow para orquestrar tudo.
Quando você percebe, já existem dashboards dependendo daquilo, alguém pediu “só um ajuste rápido” e a mudança entrou direto na main. O resultado costuma ser previsível: métrica inconsistente, tabela duplicada, dashboard quebrado e time apagando incêndio.
No entanto, Git em dados não é sobre “ser mais formal”. Na prática, é sobre construir um jeito previsível de mexer em SQL, dbt, Airflow e documentação sem quebrar o que já existe.
Por que PR é a unidade real de entrega em dados
Em times de Analytics, o maior risco não é apenas o código “dar erro”. Muitas vezes, o problema mais grave aparece de forma silenciosa no downstream: uma coluna renomeada, uma regra de métrica alterada, um join que duplicou linhas ou uma tabela que ficou cara e lenta.
Por isso, o Pull Request precisa ser tratado como a unidade real de entrega. É nele que a mudança entra em discussão, recebe revisão, passa por validação e, só então, vira “verdade” em produção.
Dessa forma, o PR deixa de ser apenas uma etapa técnica e passa a funcionar como um mecanismo de proteção para métricas, pipelines, dashboards e decisões de negócio.
Estrutura simples de repositório para dados
Uma estrutura previsível facilita o review e reduz o risco de PRs gigantes. Além disso, ajuda o time a encontrar rapidamente onde cada ativo vive.
Você não precisa inventar muito. O mais importante é separar produção de exploração e deixar claro onde ficam os ativos críticos.
Uma estrutura simples pode incluir:
- SQL utilitário e consultas versionadas;
- dbt, com models, tests, snapshots e macros;
- Airflow, com DAGs e configurações;
- docs, com dicionário, runbooks, decisões e ownership.
Quando tudo fica misturado, o time perde tempo revisando coisas irrelevantes. Pior ainda: mudanças que realmente podem quebrar a produção passam despercebidas.
Por outro lado, quando cada tipo de ativo tem um lugar claro, o review fica mais rápido, o onboarding melhora e a investigação de incidentes leva menos tempo.
Fluxo de branch que não vira burocracia
Você não precisa adotar um GitFlow completo para trabalhar bem com dados. Na maioria dos times de Analytics, um fluxo mais leve costuma resolver.
O ponto central é manter a main estável e evitar mudanças diretas em produção. Para isso, algumas regras simples já ajudam bastante:
- main sempre estável e pronta para deploy;
- branches curtas para qualquer mudança;
- nomes de branch que expliquem a intenção;
- Pull Request antes de integrar no branch principal;
- validação proporcional ao risco da mudança.
Assim, o time ganha previsibilidade sem criar burocracia desnecessária.
Convenção de nomes de branch que funciona
Branches precisam ser fáceis de entender e de buscar. Portanto, use nomes consistentes e descritivos.
Alguns padrões úteis são:
- feature/<dominio>-<assunto>
- fix/<dominio>-<bug>
- hotfix/<dominio>-<incidente>
- chore/<assunto>
Na prática, uma branch chamada feature/finance-receita-liquida comunica muito mais do que ajuste-final ou teste-query. Além disso, nomes claros melhoram a rastreabilidade. Quando algo dá errado, fica mais fácil entender qual mudança entrou, por que entrou e qual domínio foi afetado.
O que um PR “bom” precisa ter (sem virar textão)
Um PR bom não precisa ser longo. No entanto, ele precisa responder às perguntas certas. Um bom PR costuma ter três elementos: contexto, impacto e prova.
Contexto
O contexto explica, em uma frase, o que está sendo alterado.
Exemplo:
“Ajusta regra de receita líquida para excluir estornos.”
Essa frase simples já reduz ambiguidade e ajuda o revisor a entender a intenção da mudança.
Impacto
O impacto mostra o que pode ser afetado.
Exemplo:
“Modelos afetados: X. Dashboards impactados: Y. Mudou definição de métrica? Sim. Documentação atualizada em Z.”
Esse trecho poupa horas de investigação, principalmente quando a mudança atinge modelos consumidos por áreas de negócio.
Prova
A prova mostra como a mudança foi validada.
Aqui entram testes, checks, comparação antes/depois, validação de volume, análise de duplicidade e qualquer evidência de que a alteração não quebrou o que já funcionava.
Quando contexto, impacto e prova aparecem juntos, o review deixa de ser adivinhação. Como resultado, a conversa fica mais objetiva e o risco de incidente diminui.
A Atlassian tem um tutorial direto sobre o fluxo de Pull Request e como ele melhora colaboração e qualidade.
Como revisar mudanças em SQL, dbt e Airflow sem travar o time
Um review eficiente em dados não se limita à pergunta “o SQL está correto?”. Embora a sintaxe importe, ela é apenas uma parte do problema. Para revisar bem sem travar o time, combine três lentes: regra de negócio, performance e impacto downstream.
1. Regra de negócio e resultado
A primeira pergunta é: isso entrega a definição certa?
Em métricas, esse cuidado é crítico. Uma alteração pequena em filtro, join, regra de deduplicação ou janela de tempo pode mudar decisões executivas.
Por isso, o revisor precisa entender qual conceito está sendo alterado. Além disso, precisa verificar se a regra continua alinhada ao que o negócio espera medir.
2. Performance e estabilidade
Uma query pode estar correta e, ainda assim, ser cara ou frágil.
Alguns sinais de atenção incluem:
- SELECT * em produção;
- joins que multiplicam linhas;
- filtros aplicados tarde demais;
- granularidade ambígua;
- modelos dbt sem testes mínimos;
- DAGs com retries ou timeouts mal configurados;
- dependências que criam filas e atrasos no Airflow.
Portanto, o review também deve olhar para custo, tempo de execução, estabilidade e manutenção.
3. Impacto downstream
Em dados, downstream é o “cliente final” do PR. Ou seja, é tudo que depende daquela tabela, modelo, métrica ou pipeline.
Antes de aprovar uma mudança, pergunte:
- mudou o esquema?
- alguma coluna usada por dashboard foi removida ou renomeada?
- a regra de métrica mudou?
- o particionamento foi alterado?
- algum consumidor precisa ser avisado?
- a documentação foi atualizada?
Essas perguntas ajudam a evitar mudanças silenciosas. Além disso, tornam o PR mais seguro para quem consome os dados.
Para code review como prática de qualidade e compartilhamento de conhecimento, o guia do Google é uma boa referência. Ele reforça pontos como escopo pequeno, clareza, feedback acionável e foco em risco.
Regras mínimas de aprovação por criticidade
Nem toda mudança precisa do mesmo nível de rigor. Por isso, o ideal é calibrar o processo de aprovação de acordo com o risco.
Baixo risco
Mudanças de baixo risco incluem documentação, ajustes de nomenclatura, refactors sem alteração de resultado e melhorias pequenas sem impacto em produção.
Nesse caso, um review leve costuma ser suficiente.
Médio risco
Mudanças de médio risco incluem novo modelo, ajuste em mart, alteração em DAG não crítico ou mudança que afeta um consumo limitado.
Aqui, o ideal é ter pelo menos um reviewer e uma validação simples antes da aprovação.
Alto risco
Mudanças de alto risco incluem alteração de métrica, mudança de schema, DAG crítico, tabela executiva, consumo regulatório ou impacto direto em decisões de liderança.
Nesses casos, vale exigir dois reviewers, validação antes/depois e uma nota de release explicando o que mudou.
Essa gradação evita dois extremos: burocracia para mudanças simples e permissividade em alterações críticas. Dessa forma, o time continua rápido no que é simples e cuidadoso no que realmente importa.
Ownership por domínio (governança leve que evita “terra de ninguém”)
Em dados, “ninguém sabe de quem é” costuma ser uma fonte constante de incidentes.
Para evitar isso, mantenha um arquivo simples de ownership por domínio. Ele pode ser tão direto quanto:
- Finance: owner X;
- Marketing: owner Y;
- Produto: owner Z;
- Operações: owner W.
A regra também precisa ser simples: mudanças em ativos críticos de um domínio devem ter aprovação de alguém responsável por aquele domínio. Isso não é burocracia. Pelo contrário, é responsabilidade distribuída.
Quando o ownership está claro, o time sabe quem deve revisar, quem deve ser avisado e quem pode ajudar a avaliar impacto de negócio. Como resultado, a resposta a incidentes fica mais rápida e o conhecimento deixa de ficar escondido em conversas soltas.
Anti-patterns que mais causam incidentes (e como cortar)
Mudança direto na main
Quase sempre nasce de pressa e termina em retrabalho. A solução é simples: branch + PR sempre, até para hotfix (com review pós-incidente, se necessário).
PR gigante que ninguém revisa
Se mudou “muita coisa ao mesmo tempo”, ninguém consegue avaliar. A solução é fatiar por unidade de valor: uma métrica, um mart, um DAG.
Deploy sem validação
“Funcionou no meu notebook” é o início do incidente. O mínimo é ter checks antes/depois e testes essenciais.
Mudança silenciosa de métrica
Se a definição mudou, trate como mudança de produto: documente e avise.
Fechamento
Git para dados não precisa ser pesado. Precisa ser previsível. Com branches curtas e bem nomeadas, PRs com contexto, impacto e prova, reviews focados em resultado, performance e downstream, aprovação por criticidade e ownership por domínio, o time reduz incidentes sem perder velocidade.
Na prática, essa disciplina ajuda a transformar SQL, dbt, Airflow e documentação em ativos confiáveis. Além disso, melhora a colaboração entre Analytics, Engenharia de Dados, Produto e áreas de negócio.
Se o seu time está construindo uma base de produção em dados, com SQL avançado, modelagem, orquestração e entrega com padrão, essa mentalidade se conecta bem com a prática do Bootcamp Data Analytics & AI da Tekne. Afinal, a habilidade não é apenas escrever query. É entregar com confiabilidade.
