E Se Seu Histórico Git Fosse um Banco de Dados SQL?

O Pgit não é um fork do Git nem uma camada de abstração sobre ele: é uma reimplementação radical que troca o sistema de objetos imutáveis (blobs, trees, commits) por uma arquitetura relacional versionada. Ele modela commits como linhas em uma tabela commits, arquivos como versões em file_versions, e diffs como entradas em patches, todas interligadas por chaves estrangeiras. Isso permite queries como SELECT file_path, COUNT(*) FROM commits c JOIN file_versions fv ON c.id = fv.commit_id WHERE c.author LIKE '%backend%' GROUP BY file_path ORDER BY 2 DESC LIMIT 5, algo impossível nativamente no Git sem parsear manualmente cada commit. A compressão delta via pg-xpatch opera em nível de coluna, não de objeto, e aproveita a ordem temporal implícita dos commits para codificar apenas as mudanças entre versões sucessivas de cada arquivo, com média de 2 bytes por delta em cenários reais.

A escolha do PostgreSQL não é meramente técnica: ela impõe um trade-off explícito. O Docker/Podman é obrigatório localmente porque pg-xpatch exige compilação de extensão C com suporte a WAL personalizado e triggers de versão, recursos ausentes no SQLite e incompatíveis com a filosofia 'zero-config' do Git. Isso limita o uso a ambientes com infraestrutura de containerização, mas abre espaço para integração direta com ferramentas de BI, alertas em tempo real via LISTEN/NOTIFY, ou até fine-grained row-level security para auditoria de histórico em equipes reguladas.

Desenvolvedores gastam até 30% do tempo tentando entender código antigo, não por falta de documentação, mas pela dificuldade de extrair padrões de evolução do histórico. O Pgit transforma esse esforço em consultas repetíveis: identificar quais módulos têm churn >40% nos últimos 90 dias, cruzar autores com hotspots de bugs reportados no Jira, ou medir bus factor com base em quem realmente alterou cada linha nas últimas 10 versões, tudo em SQL, sem scripts ad-hoc em Python ou ferramentas de terceiros. Não é sobre substituir o fluxo de trabalho, mas sobre fechar a lacuna entre o que o Git armazena e o que os times precisam analisar para priorizar refatorações, avaliar riscos técnicos ou justificar investimentos em manutenção.