Leia status, diff e log e configure o .gitignore

Você já cria commits; agora precisa enxergar o estado antes de mudar o histórico. Esta aula combina status, diff, log, show e .gitignore num diagnóstico único. O objetivo é parar de usar add, commit e restore como tentativas.

Prepare quatro situações no catálogo: modifique README.md sem add; modifique catalogo.txt, execute add e modifique de novo; prepare um novo politica.txt; deixe notas.txt sem rastrear. Então leia:

git status --short

Você deve encontrar M, MM, A e ??. A coluna esquerda compara HEAD com stage. A direita compara stage com working tree. Pense num relatório de separação da livraria: o lado preparado vai para o próximo pacote; o lado da bancada ainda pode mudar. O limite é que o índice não é caixa física e guarda conteúdo, não apenas nomes.

Compare os dois lados explicitamente:

git diff
git diff --cached

O primeiro mostra mudanças ainda fora do stage; o segundo mostra a proposta do commit. Antes de registrar, leia ambos. Um diff grande demais para revisar é um sinal de que a tarefa ou o commit precisa ser dividido.

No histórico, prefira uma visão compacta e preserve o grafo:

git --no-pager log --oneline --graph --decorate --all
git --no-pager show --stat HEAD

log encontra a versão; show abre metadados e patch. Filtros como --author, --since, -S'termo' e -- caminho transformam o histórico numa pergunta. git blame aponta o último commit por linha, mas é início da investigação, não ferramenta para culpar alguém.

Agora crie regras mínimas:

node_modules/
dist/
*.log
.env
!.env.example

Esse bloco é o conteúdo de .gitignore, não comandos. Diretórios de dependências e build são reconstruíveis; logs são locais; .env pode conter segredo; o modelo sem credencial precisa continuar versionado. Não cole listas enormes sem entender: uma regra *.json esconderia manifestos importantes.

Peça ao Git que explique cada decisão:

git check-ignore -v node_modules/pacote/index.js dist/app.js logs/app.log

A saída informa arquivo de regras, linha e padrão vencedor. Essa ferramenta é mais confiável que alternar exclamações até o status “parecer certo”. Depois adicione .gitignore e .env.example ao commit.

Se .env já era rastreado, ignore não basta:

git rm --cached .env
git log --all --oneline -- .env

O primeiro prepara a remoção sem apagar o arquivo local. O segundo prova se o conteúdo ainda aparece no histórico. Se havia credencial verdadeira, revogue-a primeiro. Reescrever histórico não apaga cópias, logs nem caches externos.

O erro típico é confundir working tree limpa com aplicação correta. Git responde sobre versões; testes respondem sobre comportamento. Outro é apagar um arquivo gerado que o time realmente precisava porque o README não explicava como reconstruí-lo. Toda regra de ignore deve ter uma justificativa e um comando de reprodução.

Feche montando uma pequena tabela em suas notas: símbolo do status, estado e próxima pergunta. A missão está completa quando você encontra uma mudança por texto no log, explica MM sem consultar e usa check-ignore -v para provar a regra. Na próxima aula, essas ferramentas vão acompanhar branches, merge e um conflito proposital.