Come usare Git con un'app creata con l'IA

Per usare Git con un'app creata con l'IA, collega il progetto a un repository Git, fai un commit dopo ogni modifica che funziona, scrivi un messaggio di una riga che dica cosa è cambiato e tieni i segreti fuori con un .gitignore. Usa un branch per tutto ciò che è rischioso, esegui il pull prima di scrivere un nuovo prompt se qualcun altro ha modificato il codice e, quando l'IA rompe qualcosa, torna all'ultimo commit funzionante invece di scrivere prompt sopra il pasticcio.

Git è il controllo di versione: una cronologia di ogni versione salvata del tuo codice. GitHub è un sito che ospita online i repository Git. Se sono concetti nuovi per te, inizia da cos'è GitHub. Questa guida riguarda le abitudini che rendono Git utile quando è un'IA a scrivere la maggior parte del codice.

Perché Git conta di più con l'IA

Un'IA può modificare venti file in un solo turno. È veloce, ma significa anche che un prompt può rompere in silenzio qualcosa che avevi testato ieri. Git ti dà:

• Un modo per tornare indietro. Qualsiasi versione salvata può essere ripristinata.
• Una traccia di cosa è cambiato. Puoi vedere esattamente quali file e quali righe ha toccato un prompt.
• Una copia al di fuori del builder. Il tuo codice vive in un posto che controlli tu.
• Un passaggio di consegne standard. Qualsiasi sviluppatore, hosting o strumento può lavorare da un repository Git.

Passo 1: collega un repository

Crea un repository (di solito privato) su GitHub o su un servizio simile e collega il tuo progetto. La maggior parte dei builder di app con IA che supportano Git lo fa da una pagina delle impostazioni con un pulsante "Connect GitHub". Se il tuo non lo prevede, puoi esportare il codice e caricarlo tu stesso, oppure chiedere a uno sviluppatore di configurarlo una volta.

Prima del primo push, assicurati che il repository ignori le cose che non devono starci:

Controlla il file .gitignore. Assicurati che escluda i file .env, node_modules, le cartelle di build e qualsiasi file con segreti. Dimmi cosa hai aggiunto.

Passo 2: fai un commit dopo ogni modifica funzionante

Un commit è uno snapshot salvato con un messaggio. L'abitudine che conta: fai il commit quando qualcosa funziona, prima di chiedere la cosa successiva.

1. Chiedi una sola modifica.
2. Verificala nell'anteprima.
3. Se funziona, fai il commit (o la sincronizzazione) con un messaggio.
4. Poi passa oltre.

Commit piccoli significano che, quando qualcosa si rompe, sai quale modifica l'ha causato, e annullarla non butta via il resto del lavoro.

Passo 3: scrivi messaggi che potrai leggere in seguito

Un buon messaggio dice cosa è cambiato e perché, in una riga:

• Buono: Aggiunge l'esportazione CSV alla pagina degli ordini
• Buono: Corregge il modulo di prenotazione che rifiutava gli orari dopo le 18
• Non utile: update, modifiche, sistemo roba

Puoi chiedere all'IA di scriverli:

Riassumi in una riga le modifiche dall'ultimo commit, iniziando con un verbo, sotto i 70 caratteri.

Passo 4: usa i branch per il lavoro rischioso

Un branch è una linea di lavoro separata. Puoi provare qualcosa su un branch e, se non funziona, abbandonarlo senza toccare la versione principale.

Usa un branch quando:

• La modifica è grande (un redesign, un nuovo flusso di pagamento, una modifica al database).
• Qualcun altro sta lavorando sulla stessa app.
• Vuoi che qualcuno controlli la modifica prima che vada online.

Quando il lavoro è completato e testato, viene unito (merge) al branch principale. Su GitHub questo di solito avviene tramite una pull request, una pagina che mostra le modifiche da revisionare. Se il tuo builder sincronizza un solo branch, uno sviluppatore può gestire i branch dal lato GitHub.

Passo 5: annulla in sicurezza

Quando un prompt rompe l'app, resisti alla tentazione di scrivere altri cinque prompt sopra. Torna all'ultima versione funzionante e prova un prompt più chiaro.

• Nel builder: usa la sua funzione di checkpoint o di ripristino, se ce l'ha.
• In Git: git revert crea un nuovo commit che annulla uno precedente, mantenendo intatta la cronologia. È la scelta sicura per il codice che altri potrebbero aver già scaricato.
• Evita git push --force su un branch condiviso, a meno che tu non sappia esattamente perché. Riscrive la cronologia per tutti.

Se non sei sicuro, chiedi:

L'ultima modifica ha rotto la pagina di login. Mostrami quali file ha cambiato rispetto al commit precedente e spiega cosa ha fatto ogni modifica. Non cambiare ancora nulla.

Passo 6: esegui il pull prima di scrivere un prompt

Se uno sviluppatore o un altro strumento modifica il codice su GitHub, il builder con IA non se ne accorge finché non importi quelle modifiche con un pull. Scrivere prompt su codice vecchio causa conflitti e perdita di lavoro.

• Esegui il pull all'inizio di ogni sessione.
• Concordate chi modifica cosa, ed evitate che entrambe le parti modifichino gli stessi file nello stesso momento.
• Se ottieni un conflitto di merge (due modifiche alle stesse righe), chiedi allo sviluppatore o all'IA di risolverlo e di spiegare la scelta.

Esempi di prompt

Prima di iniziare: cosa è cambiato nel repository dalla mia ultima sessione? Riassumi i commit.

Fai la prossima modifica da sola: aggiungi un pulsante "Duplica" a ogni fattura. Non cambiare nient'altro, così posso fare il commit separatamente.

Controlla che nessuna chiave API, password o file .env sia tracciato in Git, anche nei commit passati. Riporta solo i nomi dei file, non i valori.

Errori comuni

• Fare commit dei segreti. Una volta che una chiave è nella cronologia di Git, è esposta, anche dopo aver cancellato il file. Sostituiscila.
• Un unico commit gigante a settimana. Non puoi annullare una modifica senza annullarle tutte.
• Messaggi come "update". La cronologia diventa inutile per trovare cosa si è rotto.
• Scrivere prompt su codice non aggiornato. Esegui il pull prima se qualcun altro sta modificando.
• Fare force-push per correggere un errore. Può cancellare il lavoro di altre persone. Usa il revert.
• Fare commit di node_modules. È enorme e viene ricreata comunque dal file di lock.

Checklist

• Il progetto è collegato a un repository privato.
• .gitignore esclude .env, node_modules, l'output di build e i segreti.
• Faccio un commit dopo ogni modifica funzionante.
• I messaggi di commit dicono cosa è cambiato in una riga.
• Le modifiche grandi o rischiose vanno su un branch e vengono revisionate.
• Eseguo il pull prima di scrivere un prompt quando qualcun altro modifica il codice.
• Annullo con i checkpoint o con git revert, non con il force-push.
• Ogni chiave che è mai stata committata è stata sostituita.

Git su Mythex

Mythex salva un checkpoint Git dopo ogni turno riuscito dell'agente, e Ripristina a questo punto riporta il progetto a quel punto: è l'annullamento lato builder descritto nel passo 5. Vedi Itera senza ricostruire.

Nel piano Pro, la sincronizzazione con GitHub collega un repository dalle impostazioni del progetto, così puoi fare push e pull, e l'esportazione scarica il progetto senza segreti e senza node_modules. Vedi GitHub, esportazione e importazione. Collegare GitHub prima di passare un progetto a uno sviluppatore rende il passaggio molto più semplice: vedi come lavorare con uno sviluppatore su un'app creata con l'IA e come esportare e ospitare autonomamente un'app creata con l'IA.

Domande