.gitignore e boas práticas de commit

.gitignore — o que o git deve ignorar completamente

node_modules/
.env
.env.local
dist/
build/
*.log
.DS_Store

Arquivos listados aqui nunca aparecem em git status, nunca são commitados por acidente — mesmo rodando git add .. Três categorias sempre entram: dependências reinstaláveis (node_modules), saída de build (dist), e segredo (.env).

.env já commitado por engano — o problema mais sério

Se um .env com credencial de produção já foi commitado antes de entrar no .gitignore, adicionar ao .gitignore agora não remove do histórico — o segredo continua lá, em qualquer commit antigo, acessível por qualquer clone do repositório. Nesse caso a credencial precisa ser trocada/revogada, não só "escondida" — o git não apaga história retroativamente sem reescrever ela inteira (uma operação arriscada, fora do escopo desta lição).

Mensagem de commit — pra quem vai ler daqui a 6 meses

fix
ajustes
wip
asdf

Corrige validação de e-mail aceitando espaço em branco

O regex não cobria o caso de "  ana@ex.com" (espaço antes) —
usuários colando do clipboard geravam cadastro com e-mail inválido.

Primeira linha curta e no imperativo ("Corrige", não "Corrigido" ou "Corrigindo"); linha em branco; depois o porquê, se não for óbvio. git log daqui a 6 meses deveria explicar a decisão sem precisar perguntar pra ninguém.

Commits pequenos e frequentes vs. um commit gigante

Um commit por funcionalidade pequena e completa (não por "final do dia") facilita reverter só a parte que deu problema, sem levar junto outras 10 mudanças não relacionadas.