[Vibe Coder #3] Por que Git se a IA escreve o código? (rollback em 1 min)

Ao fazer vibe coding, esse dia inevitavelmente chega. Você pede à IA para adicionar um recurso a um app que funcionava bem até ontem, e ela altera tudo até o app inteiro parar de funcionar. Mesmo pedindo “Volte ao estado anterior”, a IA não consegue restaurá-lo com precisão. Ela mudou vinte lugares, e nem a própria IA sabe qual deles causou o problema.

É para esse dia que existe o Git. Muita gente pergunta: “Se a IA lembra de todo o código, por que preciso do Git?” A conclusão é a IA não consegue lembrar do código. Ela esquece quando a conversa fica longa, e uma nova conversa começa do zero. Quem lembra do passado do código não é a IA, mas o Git.

Git é o ponto de salvamento do jogo

O conceito do Git é exatamente como salvar um jogo. Você salva antes de entrar na luta contra um chefe porque, mesmo morrendo, pode recomeçar do ponto salvo. O commit(commit) do Git é esse salvamento. Cada commit preserva permanentemente um snapshot de todos os arquivos do projeto naquele momento.

Os commits se acumulam como arquivos salvos. Há um commit do momento em que o login foi concluído e outro de antes de adicionar o pagamento. Você pode voltar a qualquer momento. É disso que precisa quando a IA quebra o app. Em vez de procurar o problema entre vinte alterações, volte o projeto inteiro ao último ponto salvo.

Você só precisa conhecer quatro palavras

O Git tem dezenas de comandos, mas quem faz vibe coding precisa conhecer apenas quatro conceitos. Nem é necessário memorizar os comandos: você vai pedir à IA, em linguagem natural, para executá-los.

• repository(repository): O “depósito de dados salvos” associado à pasta do projeto. Ferramentas de programação com IA normalmente o criam no início.
• commit(commit): Um salvamento. Registra um snapshot deste momento no depósito.
• push(push): Fazer backup dos arquivos salvos na nuvem. O servidor de backup é o GitHub. É por isso que seu código sobrevive se o computador quebrar.
• rollback(restauração): Reverter o projeto inteiro para um ponto de salvamento anterior.

Um cuidado ao fazer backup no GitHub já foi abordado na parte 2. Se você deixar um repositório como Public, bots vão vasculhá-lo em poucos minutos. A menos que haja um motivo especial, deixá-lo Private(Private) é o padrão.

Ritmo prático: “um recurso, um commit”

Usar Git se resume a um hábito: salvar sempre que algo começar a funcionar corretamente.

• O login finalmente funciona → “Faça commit do estado atual”
• Antes de ajustar o design → “Faça commit antes de alterar”
• Fim do trabalho de hoje → “Faça commit e push para o GitHub”

Seja Cursor ou Claude Code, todas as ferramentas de programação com IA entendem essas instruções e fazem o trabalho por você. Você não precisa digitar os comandos. O importante é o momento. Se não salvar antes da luta contra o chefe (uma alteração grande), não terá para onde voltar quando morrer. O commit feito antes de pedir uma grande alteração à IA é o commit mais valioso.

O erro mais comum é o oposto: acumular trabalho por dias sem fazer commit e então a IA quebrar o app. Sem um ponto salvo para voltar, o código da época em que tudo funcionava desaparece para sempre. O Git também não protege alterações que não foram commitadas.

Quando der errado: rollback em 1 minuto

Se a IA quebrar o app, siga esta ordem.

1. Diga calmamente à IA: “O app quebrou depois da alteração recente. Volte ao estado do último commit.”
2. Quando a IA executa o rollback, todas as alterações posteriores ao commit desaparecem e o projeto volta ao ponto salvo.
3. Depois de confirmar que o app voltou a funcionar, tente novamente a alteração que falhou em partes menores. Não peça para alterar vinte lugares de uma vez; faça uma coisa por vez.

Aqui reaparece a distinção da parte 1. O rollback restaura apenas o código. Os dados acumulados no DB permanecem inalterados, independentemente do Git. Voltar o código para ontem não apaga os membros que se cadastraram hoje. Da mesma forma, não é possível recuperar com Git dados apagados por engano. O Git cuida do passado do código; os backups do DB cuidam do passado dos dados.

.envO mesmo vale para o arquivo. Na parte 2, ele foi registrado em .gitignore para que o Git não o acompanhasse; por isso, o Git não protege esse arquivo. Se você gerar uma nova chave, anote-a separadamente em um local seguro, como um gerenciador de senhas.

Autoverificação que você pode fazer hoje

Pergunte isto à IA.

1. “Este projeto tem um repositório Git? Quando foi feito o último commit?” — Se não houver repositório ou o último commit tiver sido há uma semana, é hora de fazer commit.
2. “Está sendo feito backup (push) para o GitHub? O repositório é público ou privado?” — Se não houver backup, peça para criar um; se estiver público, considere torná-lo privado.
3. “Quantas alterações sem commit estão acumuladas?” — Se tudo estiver funcionando bem, peça para fazer commit imediatamente.

Resumo

• A IA não consegue lembrar do passado do código. Lembrar é tarefa do Git.
• Um commit é um salvamento, um push é um backup na nuvem (GitHub) e um rollback é voltar a um ponto salvo.
• O ritmo é um só: sempre que tudo funcionar bem e antes de uma grande alteração, diga: “Faça commit”.
• O rollback restaura apenas o código. Os dados do DB e .env pertencem ao mundo fora do Git.
• A menos que haja um motivo especial, repositórios privados são o padrão.

A próxima parte é sobre deploy. Vamos explicar por que um app que funciona perfeitamente no seu computador não funciona quando vai para a Internet, e o que significam localhost, servidor, domínio e variáveis de ambiente.