Como Usar o Git com uma App Criada por IA

Para usar o Git com uma app criada por IA, ligue o projeto a um repositório Git, faça commit após cada alteração que funcione, escreva uma mensagem de uma linha a dizer o que mudou e mantenha os segredos fora com um .gitignore. Use um branch para qualquer coisa arriscada, puxe as alterações antes de voltar a fazer um prompt se outra pessoa tiver mudado o código e, quando a IA estragar algo, volte ao último commit bom em vez de fazer prompts por cima da confusão.

O Git é controlo de versões: um histórico de cada versão guardada do seu código. O GitHub é um site que guarda repositórios Git online. Se isto for novo para si, comece por o que é o GitHub. Este guia trata dos hábitos que tornam o Git útil quando é uma IA que escreve a maior parte do código.

Porque é que o Git importa mais com IA

Uma IA pode alterar vinte ficheiros num único turno. É rápido, mas também significa que um prompt pode estragar em silêncio algo que testou ontem. O Git oferece:

• Uma forma de voltar atrás. Qualquer versão com commit pode ser restaurada.
• Um registo do que mudou. Pode ver exatamente que ficheiros e linhas um prompt tocou.
• Uma cópia fora do criador. O seu código fica num sítio que controla.
• Uma passagem padrão. Qualquer programador, serviço de alojamento ou ferramenta pode trabalhar a partir de um repositório Git.

Passo 1: Ligue um repositório

Crie um repositório (normalmente privado) no GitHub ou num serviço semelhante e ligue o projeto a ele. A maioria dos criadores de apps com IA que suportam Git fazem isto numa página de definições com um botão "Ligar GitHub". Se o seu não tiver, pode exportar o código e enviá-lo você mesmo, ou pedir a um programador que configure isto uma vez.

Antes do primeiro envio, certifique-se de que o repositório ignora coisas que não devem lá estar:

Verifique o ficheiro .gitignore. Certifique-se de que exclui ficheiros .env, node_modules, pastas de build e qualquer ficheiro com segredos. Diga-me o que acrescentou.

Passo 2: Faça commit após cada alteração que funcione

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

1. Faça um prompt para uma alteração.
2. Verifique-a na pré-visualização.
3. Se funcionar, faça commit (ou sincronize) com uma mensagem.
4. Depois avance.

Commits pequenos significam que, quando algo se estraga, sabe qual alteração o causou, e desfazê-la não deita fora o resto do trabalho.

Passo 3: Escreva mensagens que consiga ler mais tarde

Uma boa mensagem diz o que mudou e porquê, numa só linha:

• Bom: Adicionar exportação CSV à página de encomendas
• Bom: Corrigir formulário de marcações que rejeitava horas depois das 18h
• Pouco útil: atualizar, alterações, corrigir coisas

Pode pedir à IA que as escreva:

Resuma as alterações desde o último commit numa só linha, começando por um verbo, com menos de 70 caracteres.

Passo 4: Use branches para trabalho arriscado

Um branch é uma linha de trabalho separada. Pode experimentar algo num branch e, se não resultar, abandoná-lo sem tocar na versão principal.

Use um branch quando:

• A alteração for grande (um redesenho, um novo fluxo de pagamento, uma alteração à base de dados).
• Outra pessoa estiver a trabalhar na mesma app.
• Quiser que alguém reveja a alteração antes de ir para produção.

Quando o trabalho estiver concluído e testado, é integrado de volta no branch principal. No GitHub, isto acontece normalmente através de um pull request, uma página que mostra as alterações para revisão. Se o seu criador só sincronizar um branch, um programador pode gerir os branches do lado do GitHub.

Passo 5: Desfaça com segurança

Quando um prompt estraga a app, resista à vontade de fazer mais cinco prompts por cima. Volte à última versão boa e tente um prompt mais claro.

• No criador: use a função de ponto de restauro, se existir.
• No Git: git revert cria um novo commit que desfaz um antigo, mantendo o histórico intacto. É a escolha segura para código que outros possam já ter puxado.
• Evite git push --force num branch partilhado, a menos que saiba exatamente porquê. Isso reescreve o histórico para todos.

Se não tiver a certeza, pergunte:

A última alteração estragou a página de início de sessão. Mostre-me que ficheiros mudou em comparação com o commit anterior e explique o que fez cada alteração. Ainda não altere nada.

Passo 6: Puxe as alterações antes de fazer prompts

Se um programador ou outra ferramenta alterar o código no GitHub, o criador de IA não sabe até você puxar essas alterações. Fazer prompts sobre código antigo causa conflitos e perda de trabalho.

• Puxe as alterações no início de cada sessão.
• Combinem quem edita o quê e evitem que os dois lados editem os mesmos ficheiros ao mesmo tempo.
• Se tiver um conflito de integração (duas alterações às mesmas linhas), peça ao programador ou à IA para o 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 alteração de forma isolada: adicione um botão "Duplicar" a cada fatura. Não altere mais nada, para que eu possa fazer commit separadamente.

Verifique se nenhuma chave de API, palavra-passe ou ficheiro .env está registado no Git, incluindo commits antigos. Indique apenas os nomes dos ficheiros, não os valores.

Erros comuns

• Fazer commit de segredos. Assim que uma chave está no histórico do Git fica exposta, mesmo depois de apagar o ficheiro. Substitua-a.
• Um commit gigante por semana. Não consegue desfazer uma alteração sem desfazer todas.
• Mensagens como "atualizar". O histórico deixa de ser útil para encontrar o que estragou.
• Fazer prompts sobre código desatualizado. Puxe primeiro quando outra pessoa estiver a editar.
• Fazer force-push para corrigir um erro. Pode apagar o trabalho de outras pessoas. Prefira reverter.
• Fazer commit de node_modules. É enorme e é recriado a partir do ficheiro de bloqueio de qualquer forma.

Lista de verificação

• O projeto está ligado a um repositório privado.
• O .gitignore exclui .env, node_modules, saída de build e segredos.
• Faço commit após cada alteração que funcione.
• As mensagens de commit dizem o que mudou numa linha.
• Alterações grandes ou arriscadas vão para um branch e são revistas.
• Puxo as alterações antes de fazer prompts quando outra pessoa edita o código.
• Desfaço com pontos de restauro ou git revert, nunca com force-push.
• Qualquer chave que alguma vez tenha sido enviada foi substituída.

Git no Mythex

O Mythex guarda um ponto de restauro do Git após cada turno bem-sucedido do agente, e Reverter para este ponto repõe o projeto nesse estado — o desfazer do lado do criador descrito no passo 5. Veja Iterar sem reconstruir.

No Pro, a sincronização com o GitHub liga um repositório nas definições do projeto para que possa enviar e puxar alterações, e a exportação descarrega o projeto deixando de fora os segredos e o node_modules. Veja GitHub, exportação e importação. Ligar o GitHub antes de entregar um projeto a um programador torna a passagem muito mais simples — veja como trabalhar com um programador numa app criada por IA e como exportar e alojar por conta própria uma app criada por IA.

Perguntas