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 são 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. Resultado: métrica inconsistente, tabela duplicada, dashboard quebrado e o time apagando incêndio.
Git em dados não é sobre “ser mais formal”. É 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 é o código “dar erro”. É o impacto silencioso no downstream: uma coluna renomeada, uma regra de métrica que mudou, um join que duplicou linhas, uma tabela que ficou cara e lenta.
Por isso, Pull Request precisa ser tratado como a unidade de entrega: onde a mudança é proposta, discutida, revisada e validada antes de virar “verdade” em produção. O GitHub define PR exatamente como esse mecanismo de propor mudanças e revisar antes de integrar ao branch principal.
Estrutura simples de repositório para dados
Uma estrutura previsível facilita review e reduz PR gigante. Você não precisa inventar muito. O importante é separar “produção” de “exploração” e deixar claro onde vivem os ativos críticos:
- SQL utilitário e consultas versionadas
- dbt (models, tests, snapshots e macros)
- Airflow (dags e configs)
- docs (dicionário, runbooks, decisões e ownership)
Quando tudo fica misturado, o time perde tempo revisando coisas irrelevantes e, pior, deixa passar o que realmente quebra a produção.
Fluxo de branch que não vira burocracia
Você não precisa de GitFlow completo. Um fluxo leve costuma bastar:
- main sempre estável e pronta para deploy
- branches curtas para qualquer mudança
- nomes de branch que digam a intenção
Convenção de nomes de branch que funciona
Use nomes “buscáveis” e consistentes, por exemplo:
- feature/<dominio>-<assunto>
- fix/<dominio>-<bug>
- hotfix/<dominio>-<incidente>
- chore/<assunto>
Isso melhora a rastreabilidade e reduz tempo de investigação quando algo dá errado.
O que um PR “bom” precisa ter (sem virar textão)
PR bom tem três coisas: contexto, impacto e prova.
Contexto é uma frase simples: “ajusta regra de receita líquida para excluir estornos”.
Impacto é a parte que poupa horas: “modelos afetados X; dashboards Y; mudou definição? sim/não; doc atualizada onde”.
Prova é como você validou: testes, checks e comparação antes/depois.
Quando essas três coisas estão presentes, o review deixa de ser adivinhação. A Atlassian tem um tutorial bem direto sobre o fluxo de PR e por que ele melhora a colaboração e qualidade.
Como revisar mudanças em SQL, dbt e Airflow sem travar o time
Um review eficiente em dados não é só “o SQL está correto?”. Ele combina três lentes:
1) Regra de negócio e resultado
A pergunta é: “isso entrega a definição certa?”. Em métricas, isso é crítico. Uma mudança pequena pode alterar decisões.
2) Performance e estabilidade
Uma query pode estar correta e ainda assim ser cara ou frágil: SELECT * em produção, joins que explodem linha, falta de filtro cedo, granularidade ambígua. Em dbt, modelos sem testes mínimos podem virar bomba-relógio. Em Airflow, retries/timeout mal configurados criam filas e atrasos.
3) Impacto downstream (o que quebra depois)
Mudou o esquema? Mudou coluna usada por dashboard? Mudou o particionamento? Mudou regra de métrica? Em dados, downstream é o “cliente final” do PR.
Para code review como prática de qualidade e compartilhamento de conhecimento, o guia do Google é excelente e aplica muito bem em times de dados: escopo pequeno, clareza, feedback acionável e foco em risco.
Regras mínimas de aprovação por criticidade
Para não virar burocracia, calibre rigor pelo risco:
- Baixo risco (docs, refactor sem alterar resultado): review leve
- Médio risco (novo modelo, ajuste em mart, DAG não crítico): 1 reviewer + validação simples
- Alto risco (mudança de métrica, schema, DAG crítico, consumo executivo): 2 reviewers + validação antes/depois + nota de release
Essa gradação deixa o time rápido no 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 é” é uma fonte constante de incidentes. Um arquivo simples de ownership (por domínio) resolve boa parte:
- Finance: owner X
- Marketing: owner Y
- Produto: owner Z
A regra é: mudanças em ativos críticos do domínio precisam de alguém do domínio aprovando. Isso não é burocracia; é responsabilidade distribuída.
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. Branch curta e nomeada, PR com contexto/impacto/prova, review com foco em resultado, performance e downstream, criticidade para calibrar rigor e ownership para evitar “terra de ninguém”. Isso reduz incidentes e aumenta a velocidade com segurança.
Se o seu time está construindo base de produção em dados (SQL avançado, modelagem, orquestração e entrega com padrão), essa mentalidade conecta bem com a prática do Bootcamp Data Analytics & AI da Tekne: a habilidade não é só escrever query, é entregar com confiabilidade.
