Testar e corrigir com a IA, com versões salvas no git

Nesta aula

Tudo vai quebrar em algum momento. A diferença entre pânico e rotina é saber ler o erro e ter para onde voltar.

Programador experiente não erra menos; ele tem um método para quando erra. Duas partes: ler o erro com calma e pedir a correção certa, e ter cada versão que funcionou guardada, para voltar em segundos quando a correção piora as coisas. Nesta aula você aprende as duas. A segunda usa o git, uma ferramenta que assusta pelo nome, mas que para o nosso uso são quatro comandos.

• Ao final, você vai saber ler uma mensagem de erro e transformá-la num pedido de correção que a IA resolve de primeira.
• Vai entender o que é git, o que é um commit, e usar os quatro comandos que bastam.
• Vai sair com três erros corrigidos e três versões salvas no histórico do seu projeto.

Ler o erro: onde ele aparece e o que ele diz

Quando algo dá errado, quase sempre existe uma mensagem. O problema é que ela aparece em lugares que a maioria das pessoas não olha:

• No terminal, quando o servidor da aula 8 não sobe ou um comando falha. As últimas linhas costumam ter a causa.
• No console do navegador, quando um botão não faz nada. Aperte F12 (ou botão direito, "inspecionar") e abra a aba "Console". Erros aparecem em vermelho, com o nome do arquivo e a linha.
• Na própria tela, quando o app foi feito para mostrar erros claros (como você pediu na aula 8).

Você não precisa entender a mensagem. Precisa copiá-la inteira. Uma mensagem como TypeError: Cannot read properties of null (reading 'value') at index.html:87 diz muito para a IA: o tipo do erro, o que estava tentando ler, o arquivo e a linha. Para você, basta saber que "linha 87 do index.html" é onde olhar.

O pedido de correção que funciona

Quatro ingredientes: o sintoma, a mensagem de erro colada, o que você fez, o que esperava. E o limite "só esse problema". Com isso, a IA acerta na maioria das vezes. Sem isso, ela chuta, e o chute pode quebrar outra coisa.

Git: o que é, sem mistério

O git é um programa que guarda o histórico de um projeto. Cada vez que você "salva uma versão" (o nome disso é commit), o git tira uma foto de todos os arquivos da pasta e guarda com uma mensagem sua. Você pode ver a lista de fotos, comparar duas, e voltar a qualquer uma. É a cópia index-v1.html da aula 5, só que automática, para todos os arquivos, com histórico e sem bagunça de nomes.

Tudo acontece no seu computador, numa pasta escondida chamada .git dentro da pasta do projeto. Nada vai para a internet a menos que você mande (e neste curso não vamos mandar; os serviços de hospedagem que "conectam a um repositório" usam isso, mas fica para depois).

O git precisa estar instalado. No Mac e no Linux costuma vir ou ser instalado com um comando do sistema; no Windows, pela página oficial (git-scm.com). Se a ferramenta de IA disser que o git não está instalado, peça a ela o passo a passo para o seu sistema, ou instale pela página oficial. O Cursor e o Claude Code trabalham bem com o git, e inclusive podem rodar os comandos para você, mas aprenda a rodar você mesmo: são quatro.

Os quatro comandos

Na primeira vez, o git pode pedir para você dizer seu nome e e-mail (é a assinatura das fotos). Ele mostra os dois comandos para isso na própria mensagem; copie e rode. Depois, o ciclo é sempre git add . e git commit -m "...".

Uma boa mensagem de commit

A mensagem é para você daqui a três meses. "ajustes" não diz nada. "corrige botão exportar que não baixava o arquivo" diz tudo. Regra: o que mudou e por quê, em uma linha. Exemplos que uso:

git commit -m "primeira versão do cadastro de pedidos"
git commit -m "impede adicionar com cliente vazio"
git commit -m "corrige soma por prato depois de apagar item"
git commit -m "botões maiores no celular"

Rode git log --oneline e você vê a história do projeto em ordem. É o primeiro documento de manutenção que existe, e ele se escreve sozinho se as mensagens forem boas.

O que nunca entra no histórico

Lembra da chave de API da aula 8? Se ela está num arquivo .env na pasta, o git add . vai colocá-la no histórico. E o que entra no histórico é difícil de tirar: mesmo apagando o arquivo depois, a versão antiga continua guardada. Se um dia você compartilhar a pasta ou conectar a um serviço, a chave vai junto.

A proteção é um arquivo chamado .gitignore, na raiz da pasta, com a lista do que o git deve ignorar. Uma linha por item:

.env
*.log
node_modules/

A primeira linha é a chave. As outras são coisas que a IA pode ter criado e que não são código seu (registros de execução, pastas de bibliotecas baixadas). Peça à IA: "crie um .gitignore adequado para este projeto, incluindo obrigatoriamente o .env e qualquer arquivo com credencial". Depois confira que o .env está lá.

Voltar atrás quando a correção piora

O cenário: você pediu uma correção, a IA mexeu em cinco lugares, e agora dois botões pararam. Com o histórico, você tem opções, e a mais simples nem exige comando novo: diga à IA "a última mudança quebrou os botões X e Y; use o git para desfazer as alterações que ainda não foram commitadas e me mostre o que voltou". Ela sabe fazer isso, e você aprova cada passo. Se o commit já foi feito, peça "volte o arquivo index.html para a versão do commit anterior e me explique o que vai mudar". O ponto é: o histórico existe, e a IA sabe usá-lo se você pedir.

Por isso o ritmo importa: commit a cada mudança pequena que funcionou. Se você fez um commit por correção, voltar uma versão perde só aquela correção. Se fez um commit por dia, voltar perde o dia.