Cos'è GitHub? Controllo di versione per chi non è sviluppatore

GitHub è un sito web che conserva il codice dei progetti software insieme alla loro cronologia completa, così puoi vedere ogni modifica, annullare gli errori e lavorare sullo stesso progetto con altre persone. Si basa su Git, un software gratuito che registra istantanee dei file di un progetto nel tempo. Git è lo strumento che conserva la cronologia; GitHub è la casa online dove quella cronologia viene condivisa, salvata e discussa.

Se costruisci con l'AI, GitHub serve soprattutto a due cose: avere una copia del tuo codice al di fuori dello strumento con cui l'hai costruito, e consegnarlo a uno sviluppatore nel formato che già usa.

Perché conta quando costruisci con l'AI

Un app builder AI scrive e modifica molto codice in fretta, e non ogni modifica è un miglioramento. Il controllo di versione serve a mantenere tutto al sicuro.

Annulla con sicurezza. Ogni modifica salvata è un'istantanea. Se l'AI rompe qualcosa, torni all'ultima versione funzionante.
Proprietà. Il codice nel tuo account GitHub resta tuo se cambi strumento, smetti di pagare uno strumento o vuoi un secondo parere.
Lavorare con gli sviluppatori. Quasi ogni sviluppatore usa Git ogni giorno. Un repository gli permette di controllare cosa ha scritto l'AI, correggerlo e rimandare le modifiche.
Pubblicare altrove. Molte piattaforme di hosting possono pubblicare direttamente da un repository GitHub.

Un esempio quotidiano: controllo delle modifiche più un drive condiviso

Pensa a un documento con la modalità revisione attiva, conservato in un drive condiviso.

Git è la modalità revisione: ogni modifica viene registrata, con chi l'ha fatta, quando e perché, e puoi tornare a qualsiasi versione.
GitHub è il drive condiviso: il documento vive online, altri possono ottenerne una copia e c'è un posto dove commentare e approvare.
Un branch (ramo) è come salvare una copia chiamata «bozza — nuova sezione prezzi» per sperimentare senza toccare la versione su cui tutti contano. Se l'esperimento funziona, lo riporti nella versione principale con un merge.

La differenza rispetto a un documento è la scala. Un'app è fatta di centinaia di file, e Git li traccia tutti insieme, quindi un'istantanea è lo stato dell'intero progetto in un colpo solo.

Termini di Git e GitHub che incontrerai

Termine	Significato semplice
Repository (repo)	Una cartella di progetto con la sua cronologia completa
Commit	Un'istantanea salvata delle modifiche, con un breve messaggio che le descrive
Branch	Una linea di lavoro separata, così gli esperimenti non disturbano la versione principale
main	Il nome abituale del branch principale, cioè la versione che va online
Merge	Portare le modifiche di un branch dentro un altro
Conflitto di merge	Due modifiche hanno toccato le stesse righe; qualcuno deve scegliere quale tenere
Clone	Scaricare una copia completa di un repository, cronologia inclusa
Push / pull	Inviare i tuoi commit su GitHub / portare giù i commit degli altri
Pull request (PR)	Una pagina di GitHub che propone di unire un branch, dove le persone revisionano e discutono le modifiche
Fork	Una tua copia del repository di qualcun altro, su GitHub
Issue	Un to-do o una segnalazione di bug collegata al repository
`.gitignore`	Un elenco di file che Git non deve mai registrare, come i segreti in `.env` e le dipendenze scaricate
GitHub Actions	Automazioni che girano su GitHub, per esempio i test a ogni pull request

Due punti meritano attenzione. Primo, la cronologia di Git è permanente per progetto: se una password viene committata e inviata, eliminarla in un commit successivo non la rimuove dalla cronologia. Secondo, un commit vale quanto il suo messaggio. «Correggi doppia prenotazione quando due persone prenotano insieme» ti aiuta in seguito; «aggiornamento» no.

Esempio pratico: consegnare a un freelance un'app costruita con l'AI

Hai costruito un portale clienti con un app builder AI. Funziona, ma vuoi che uno sviluppatore freelance aggiunga un'integrazione delicata con il tuo software di contabilità.

Collega il progetto a un nuovo repository privato su GitHub e invia il codice. Il repo ora contiene il codice e la sua cronologia.
Controlla cosa c'è dentro. Apri il repo su GitHub. Non dovrebbe esserci nessun file .env né chiavi API nel codice. I segreti restano nelle impostazioni della piattaforma e, se li condividi, lo fai separatamente con il freelance; vedi variabili d'ambiente e segreti.
Invita il freelance come collaboratore solo su quel repository.
Lavora su un branch chiamato qualcosa come accounting-sync, fa commit man mano e apre una pull request a lavoro finito.
Revisioni la pull request. Anche senza leggere il codice, puoi leggere la descrizione, vedere quali file sono cambiati e fare domande nei commenti.
Fai il merge quando sei soddisfatto, poi fai il pull delle modifiche nel tuo app builder così tu e l'AI continuate dalla nuova versione.

Lungo il percorso puoi vedere esattamente cosa è cambiato e annullarlo se serve. È l'intero valore del controllo di versione in un solo flusso di lavoro. Se stai valutando se coinvolgere uno sviluppatore, vedi assumere uno sviluppatore o costruire con l'AI.

Errori comuni e idee sbagliate

«GitHub e Git sono la stessa cosa». Git funziona senza GitHub; alternative come GitLab e Bitbucket ospitano anch'esse repository Git.
«GitHub farà girare la mia app». GitHub conserva il codice. Farla girare per il pubblico è web hosting, un servizio separato (anche se alcuni host pubblicano direttamente da GitHub).
Committare segreti. L'errore più dannoso e più comune. Usa .gitignore per i file .env e ruota ogni chiave che sia mai stata inviata.
Un solo branch e nessun messaggio. Va bene per esperimenti da soli, ma dai ai commit messaggi chiari e usa i branch per tutto ciò che è rischioso.
Modificare in due posti contemporaneamente. Se cambi il codice su GitHub e nel tuo app builder AI senza fare il pull in mezzo, crei conflitti. Scegli un solo posto in cui modificare alla volta e sincronizza prima di cambiare.
Pensare che un repo privato sia un backup di tutto. Contiene il codice, non il contenuto del database né i file caricati. Quelli richiedono backup propri.

Cosa chiedere al tuo app builder AI

«Aggiungi un .gitignore che escluda .env, le cartelle delle dipendenze e l'output di build.»
«Scrivi un README che spieghi come installare, quali variabili d'ambiente servono (solo i nomi) e come avviare l'app.»
«Aggiungi un .env.example con ogni nome di variabile e nessun valore reale.»
«Usa messaggi di commit chiari e descrittivi per ogni modifica.»

Queste quattro richieste creano un repository che uno sviluppatore può prendere in mano in pochi minuti. Per spostare l'app sui tuoi server, vedi come esportare e self-hostare un'app costruita con l'AI, e per renderla pronta per utenti reali, portare un prototipo AI in produzione.

GitHub e Mythex

Mythex conserva la cronologia per te su ogni piano: dopo ogni turno riuscito dell'agente salva un checkpoint, cioè un'istantanea Git a cui puoi tornare. Con Pro puoi collegare GitHub e fare push o pull del progetto sul tuo repository, oppure scaricare l'intero progetto come archivio; segreti e dipendenze installate vengono esclusi dalle esportazioni. Qui GitHub serve a sincronizzare il codice, non ad accedere a Mythex. Vedi GitHub, esportazione e importazione nella documentazione e la pagina dei prezzi per ciò che include ogni piano.

Domande

Qual è la differenza tra Git e GitHub?

Git è un software gratuito che registra la cronologia dei file di un progetto su qualsiasi computer. GitHub è un sito web, di proprietà di Microsoft, che ospita online i repository Git e aggiunge strumenti di collaborazione come pull request, issue e automazioni.

Mi serve GitHub per creare un'app con l'AI?

No. Molti app builder AI conservano la cronologia per te all'interno del prodotto. GitHub diventa utile quando vuoi una tua copia del codice, quando lavori con uno sviluppatore o quando prevedi di ospitare l'app altrove.

GitHub è gratuito?

GitHub ha un piano gratuito che include repository pubblici e privati, sufficiente per la maggior parte dei singoli e dei piccoli team. I piani a pagamento aggiungono la gestione del team e funzioni extra; per i dettagli aggiornati consulta la pagina dei prezzi di GitHub.

Il mio codice è pubblico su GitHub?

Solo se rendi pubblico il repository. I repository privati sono visibili soltanto a te e alle persone che inviti. Anche in un repository privato, non salvare mai password o chiavi API nei commit.