Um segredo foi comitado: o que fazer, e por que ordem
Acontece a toda a gente. Um .env que escapou ao .gitignore, uma chave colada num ficheiro de configuração "só para testar", um token numa mensagem de commit. E há uma reação instintiva que é a errada.
1. A ordem certa é esta
A primeira coisa não é limpar o histórico. É rodar o segredo.
A partir do momento em que a chave foi para um repositório — sobretudo público — considere-a comprometida. Há robôs a varrer commits em tempo real, e chaves de fornecedores de nuvem são usadas em minutos. Limpar o histórico primeiro é gastar meia hora a esconder uma chave que já foi copiada.
Gerar a nova.
Pôr a nova em produção.
Revogar a antiga — este passo é o que importa, e é o que se esquece.
Só depois, arrumar o histórico.
2. Tirar do histórico
Apagar o ficheiro num commit novo não chega: ele continua em todos os commits anteriores. É preciso reescrever a história:
git filter-repo --invert-paths --path .envIsto muda o identificador de todos os commits a partir dali. Num projeto seu, é um force push e está resolvido; numa equipa, é combinar com toda a gente, porque todos vão ter de voltar a clonar. E se o repositório for público, assuma que alguém já tem uma cópia.
3. Não voltar a acontecer
# .gitignore
.env
*.pem
*.keyE o ficheiro que evita metade dos casos: um .env.example versionado, com as chaves todas e os valores vazios. Quem clona sabe o que precisa de preencher, e ninguém tem a tentação de comitar o verdadeiro para "o outro ver quais são".
# .env.example
DATABASE_URL=
AUTH_SECRET=
API_KEY=4. Uma rede antes do commit
# .husky/pre-commit
if git diff --cached --name-only | grep -qE '(^|/)\.env$'; then
echo "Está a comitar um .env. Não."
exit 1
fiCinco linhas que apanham o caso mais comum. Para levar a sério, há ferramentas dedicadas a procurar segredos no que vai ser comitado — mas a rede simples que existe vale mais do que a completa que ninguém instalou.
E a regra que resume tudo: um segredo que esteve num repositório não é um segredo. Rode primeiro, arrume depois.