Como Usar o Git com um App Criado com IA

Para usar o Git com um app criado por IA, conecte o projeto a um repositório Git, faça commit depois de cada mudança que funciona, escreva uma mensagem de uma linha dizendo o que mudou e mantenha os segredos fora com um .gitignore. Use uma branch para qualquer coisa arriscada, faça pull antes de pedir de novo se outra pessoa alterou o código e, quando a IA quebrar algo, volte ao último commit bom em vez de pedir mais mudanças em cima da bagunça.

Git é controle de versão: um histórico de cada versão salva do seu código. GitHub é um site que armazena repositórios Git online. Se esses termos são novidade para você, comece com o que é o GitHub. Este guia trata dos hábitos que tornam o Git útil quando uma IA escreve a maior parte do código.

Por que o Git importa mais com IA

Uma IA pode alterar vinte arquivos em um único turno. Isso é rápido, mas significa também que um prompt pode quebrar silenciosamente algo que você testou ontem. O Git oferece:

• Um jeito de voltar atrás. Qualquer versão commitada pode ser restaurada.
• Um registro do que mudou. Você vê exatamente quais arquivos e linhas um prompt tocou.
• Uma cópia fora do criador. Seu código fica em um lugar que você controla.
• Uma passagem padrão. Qualquer desenvolvedor, hospedagem ou ferramenta pode trabalhar a partir de um repositório Git.

Passo 1: conecte um repositório

Crie um repositório (geralmente privado) no GitHub ou em um serviço semelhante e conecte seu projeto a ele. A maioria dos criadores de apps com IA que suportam Git faz isso em uma página de configurações com um botão "Conectar GitHub". Se o seu não tiver, você pode exportar o código e enviá-lo você mesmo, ou pedir a um desenvolvedor para configurar uma vez.

Antes do primeiro envio, garanta que o repositório ignore o que não deve estar nele:

Verifique o arquivo .gitignore. Garanta que ele exclua arquivos .env, node_modules, pastas de saída de build e qualquer arquivo com segredos. Me diga o que você adicionou.

Passo 2: faça commit depois de cada mudança que funciona

Um commit é um instantâneo salvo com uma mensagem. O hábito que importa: faça commit quando algo funcionar, antes de pedir a próxima coisa.

1. Peça uma mudança.
2. Verifique no preview.
3. Se funcionar, faça commit (ou sincronize) com uma mensagem.
4. Só então siga em frente.

Commits pequenos significam que, quando algo quebra, você sabe qual mudança causou o problema, e desfazê-la não joga fora o resto do seu trabalho.

Passo 3: escreva mensagens que você entenda depois

Uma boa mensagem diz o que mudou e por quê, em uma linha:

• Boa: Adiciona exportação em CSV na página de pedidos
• Boa: Corrige formulário de agendamento que rejeitava horários após as 18h
• Não ajuda: update, mudanças, arrumei umas coisas

Você pode pedir à IA que as escreva:

Resuma as mudanças desde o último commit em uma linha, começando com um verbo, com menos de 70 caracteres.

Passo 4: use branches para trabalho arriscado

Uma branch é uma linha de trabalho separada. Você pode testar algo em uma branch e, se não der certo, abandoná-la sem tocar na versão principal.

Use uma branch quando:

• A mudança for grande (um redesenho, um novo fluxo de pagamento, uma mudança no banco de dados).
• Outra pessoa estiver trabalhando no mesmo app.
• Você quiser que alguém revise a mudança antes de ir ao ar.

Quando o trabalho estiver pronto e testado, ele é mesclado de volta à branch principal. No GitHub, isso geralmente acontece por meio de um pull request, uma página que mostra as mudanças para revisão. Se o seu criador só sincroniza uma branch, um desenvolvedor pode gerenciar as branches do lado do GitHub.

Passo 5: desfaça com segurança

Quando um prompt quebra o app, resista à vontade de mandar mais cinco prompts em cima dele. Volte à última versão boa e tente um prompt mais claro.

• No criador: use o recurso de checkpoint ou de restauração, se houver.
• No Git: git revert cria um novo commit que desfaz um antigo, mantendo o histórico intacto. É a escolha segura para código que outras pessoas possam ter puxado.
• Evite git push --force em uma branch compartilhada, a menos que saiba exatamente o motivo. Ele reescreve o histórico para todos.

Se tiver dúvidas, pergunte:

A última mudança quebrou a página de login. Mostre quais arquivos ela alterou em comparação com o commit anterior e explique o que cada mudança fazia. Não altere nada ainda.

Passo 6: faça pull antes de pedir

Se um desenvolvedor ou outra ferramenta mudar o código no GitHub, o criador de IA não sabe disso até você puxar essas mudanças. Pedir mudanças sobre código antigo causa conflitos e perda de trabalho.

• Faça pull no início de cada sessão.
• Combinem quem edita o quê, e evitem que os dois lados editem os mesmos arquivos ao mesmo tempo.
• Se aparecer um conflito de merge (duas mudanças nas mesmas linhas), peça ao desenvolvedor ou à IA para resolver e explicar a escolha.

Exemplos de prompts

Antes de começarmos: o que mudou no repositório desde a minha última sessão? Resuma os commits.

Faça a próxima mudança sozinha: adicione um botão "Duplicar" em cada fatura. Não altere mais nada, para que eu possa fazer o commit separadamente.

Verifique se alguma chave de API, senha ou arquivo .env está rastreado no Git, inclusive em commits antigos. Informe apenas os nomes dos arquivos, não os valores.

Erros comuns

• Enviar segredos para o Git. Quando uma chave entra no histórico, ela fica exposta mesmo depois de você apagar o arquivo. Troque-a.
• Um commit gigante por semana. Você não consegue desfazer uma mudança sem desfazer todas.
• Mensagens como "update". O histórico fica inútil para descobrir o que quebrou.
• Pedir sobre código desatualizado. Faça pull primeiro quando outra pessoa estiver editando.
• Forçar o push para corrigir um erro. Isso pode apagar o trabalho de outras pessoas. Use revert.
• Commitar node_modules. É enorme e é recriado a partir do arquivo de lock de qualquer forma.

Checklist

• O projeto está conectado a um repositório privado.
• O .gitignore exclui .env, node_modules, saídas de build e segredos.
• Faço commit depois de cada mudança que funciona.
• As mensagens de commit dizem o que mudou em uma linha.
• Mudanças grandes ou arriscadas vão para uma branch e são revisadas.
• Faço pull antes de pedir quando outra pessoa edita o código.
• Desfaço com checkpoints ou git revert, não com force-push.
• Qualquer chave que já tenha sido commitada foi trocada.

Git no Mythex

O Mythex salva um checkpoint do Git depois de cada turno bem-sucedido do agente, e Reverter para este ponto volta o projeto a ele: é o desfazer do lado do criador descrito no passo 5. Veja Iterar sem reconstruir.

No Pro, a sincronização com GitHub conecta um repositório nas configurações do projeto para que você envie e receba mudanças, e a exportação baixa o projeto deixando de fora segredos e node_modules. Veja GitHub, exportação e importação. Conectar o GitHub antes de passar um projeto a um desenvolvedor torna a passagem muito mais simples: veja como trabalhar com um desenvolvedor em um app criado por IA e como exportar e hospedar por conta própria um app criado por IA.

Perguntas