Git e revisão de código para quem trabalha com dados

Em uma frase

O fluxo existe para que a sua mudança seja revisável, repetível e reversível — e, em dados, o revisor humano cuida do que nenhuma automação pega: grão, regra de negócio e impacto em quem consome.

O fluxo, e o porquê de cada passo

O que escrever num pedido de revisão de dados

Três perguntas, e elas são diferentes das de um projeto de aplicação:

1. O que muda no número? Se a definição de um indicador mudou, isso é a informação mais importante do pedido.
2. Quem consome o modelo afetado? Vem da linhagem, e define quem precisa ser avisado.
3. Como você validou? Testes que rodaram, comparação do total com a origem, o que mais você conferiu.

Automação e pessoa: dividir por competência

Duas armadilhas específicas de dados

Credencial no repositório. O histórico é permanente: apagar num commit posterior não remove do histórico, e quem clonou antes já tem. Segredo vai para cofre, sempre.

Notebook versionado sem cuidado. Ele guarda saídas e a ordem em que as células foram executadas, o que polui o diff e esconde estado. Limpe as saídas antes de commitar, ou promova a lógica estável para um módulo e deixe o notebook como exploração.

Como responder isso em voz alta

Descreva o fluxo, não os comandos. Diga o que vai na descrição do pedido de revisão em contexto de dados. E separe explicitamente o que a automação verifica do que a pessoa revisa — é essa separação que mostra que você já revisou o trabalho de alguém, e não só leu sobre o assunto.