Isaque Victor cursos gratuitosNesta 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: lê o erro com calma e guarda cada versão que funcionou.
- Transformar uma mensagem de erro num pedido que a IA resolve
- Entender o git e usar quatro comandos
- Voltar a uma versão que funcionava
Onde o erro aparece
- No terminal, quando o servidor não sobe. As últimas linhas têm a causa.
- No console do navegador, quando um botão não faz nada. Aperte F12 e abra a aba "Console". O erro vem em vermelho.
- Na tela, se o app mostra erros claros.
Você não precisa entender a mensagem. Precisa copiá-la inteira.
O pedido de correção
São quatro ingredientes: o sintoma, a mensagem colada, o que você fez e o que esperava. Mais o limite "só esse problema".
Dica
Se a IA disser "corrigido" e o erro continuar, não repita o pedido. Cole a mensagem atual e diga que o erro é o mesmo. Na terceira tentativa sem sucesso, volte a uma versão salva.
Exemplo real
A dona de uma loja de roupas tinha uma ferramenta de controle de trocas. O botão "registrar" parou depois de um ajuste de layout. Ela abriu o console, viu o erro em vermelho, colou na conversa com os quatro ingredientes e em um minuto estava resolvido. Antes, ela achava que "tinha quebrado tudo".
Git, sem mistério
O git guarda o histórico do projeto. Cada vez que você "salva uma versão" (um commit), ele tira uma foto de todos os arquivos, com uma mensagem sua. Tudo fica no seu computador, numa pasta escondida chamada .git.
| Comando | O que faz |
|---|---|
git init | Começa o histórico (uma vez) |
git add . | Marca os arquivos mudados para a próxima foto |
git commit -m "mensagem" | Tira a foto e guarda |
git log --oneline | Lista as fotos, uma por linha |
A mensagem é para você daqui a três meses. "Ajustes" não diz nada. "Corrige o botão exportar que não baixava o arquivo" diz tudo. Faça um commit a cada mudança pequena que funcionou.
Cuidado
Crie o .gitignore com .env ANTES do primeiro git add .. Se a chave de API entrar num commit, a única saída segura é revogá-la e criar outra. Apagar o arquivo depois não tira a chave do histórico.
Coisa de profissional
O git quase nunca perde um commit de verdade. Existe um registro das últimas posições do seu projeto, o git reflog. Por padrão, ele guarda as entradas por 90 dias, e as de commits que ficaram "soltos" (por exemplo, depois de um reset ou de uma correção do último commit) por 30 dias. Se você voltou atrás e apagou uma versão boa sem querer, rode git reflog, ache o commit na lista e volte a ele. Só não conte com isso depois desse prazo.
Voltar atrás
O cenário: você pediu uma correção, a IA mexeu em cinco lugares e agora dois botões pararam. Se você fez um commit por correção, voltar uma versão perde só aquela correção. Se fez um commit por dia, perde o dia inteiro. Por isso o ritmo importa: commit pequeno e frequente. Para voltar, peça à IA: "a última mudança quebrou o menu; volte o projeto ao último commit".
Prática · 10 min
- Peça à IA um
.gitignorepara o projeto. Depois rodegit init,git add .egit commit -m "primeira versão". - Provoque um erro de propósito (por exemplo, apague uma linha do arquivo). Copie a mensagem e peça a correção com os quatro ingredientes.
- Quando funcionar, faça um commit com mensagem clara e rode
git log --oneline.
Resumo
- Copie a mensagem de erro inteira e use os quatro ingredientes.
- Git guarda versões no seu computador: init, add, commit e log.
- Crie o .gitignore antes do primeiro commit.
- Commit pequeno e frequente deixa voltar atrás com pouca perda.
Fontes
Lidas em 30 de outubro de 2026.
- Git. git-gc: gc.reflogExpire (90 dias) e gc.reflogExpireUnreachable (30 dias).
Quiz da aula
Três situações para aplicar o que viu.