Programação & Web
Cursor / Copilot
Arqueologia de Git: por que esse código é desse jeito
Investiga o histórico de um arquivo e explica o 'porquê' dos hacks e special cases, com autor, PR e bug recorrente.
0cópias
0joinhas
0favoritos
O prompt
Faça uma arqueologia de git em {{arquivo_ou_pasta}}. Não mude nada - investigue e rapporte.
1. Resuma como o arquivo evoluiu: fases (quem reescreveu o quê, quando), em ordem cronológica.
2. Para os 5 blocos mais prováveis de confundir (hacks, special cases, comentários 'Nao apague'), explique o PORQUÊ usando commit message, PR e issue associadas - cite o hash de cada um.
3. Quem são os autores recorrentes (a quem perguntar) e quais áreas do arquivo estão abandonadas há mais tempo.
4. Sinais de design ruim: trechos onde o MESMO bug foi corrigido 2+ vezes (compare mensagens de commit parecidas).
5. Workaround que virou permanente: algo introduzido como temporário que nunca foi removido.
6. Feche com 3 refactorizações seguras que respeitam a história (o que cada uma preservaria dos commits que a explicam).
Formato: relatório markdown com tabela bloco → motivo → commit → autor → data.
Como usar
- Funciona melhor em agente com terminal (roda git log --follow -p e git blame sozinho); em chat comum, cole a saída de 'git log --follow -p {{arquivo}}' antes do prompt.
- Use antes de refatorar código antigo - o 'porquê' histórico evita re-introduzir o bug que aquele hack corrigia.
- Cole o relatório na issue do refactor: economiza a reunião com o dev veterano.
- Se o repo usa squash merge, peça para checar também o corpo dos commits e mensagens de PR via gh CLI.
Exemplo de saída
Relatório de billing.ts: special case 'trial' nasceu no PR #214 (migração fiscal de 2023, commit a3f19c); timeout corrigido 2x (commits 7c2be e f11d0 - mesmo sintoma, causas diferentes) → sinal de que retry deveria ser centralizado; workaround 'sleep 500ms' entrou como temporário em 2022 e nunca saiu; 3 refactorizações propostas preservando as regras fiscais do histórico.