GitHub è una piattaforma per gestire, condividere e sviluppare progetti basati su Git. Permette di conservare repository online, tenere traccia delle modifiche, collaborare sul codice, discutere problemi, revisionare contributi, automatizzare test e deploy e organizzare il lavoro di un team.
Ridurre GitHub a un semplice “posto dove salvare codice”, però, oggi sarebbe troppo limitante. Attorno al repository esiste un intero ambiente di sviluppo: issue, pull request, Projects, Actions, Codespaces, strumenti di sicurezza e funzionalità basate sull’intelligenza artificiale.
Se parti da zero, il punto più importante è capire come si collegano Git, repository locale e GitHub. Una volta chiaro questo meccanismo, concetti come commit, branch, fork e pull request smettono di sembrare termini separati e diventano parti dello stesso workflow.
In questa guida vedremo quindi cos’è GitHub, a cosa serve, come funziona e come usarlo concretamente, senza trasformare l’articolo in un manuale enciclopedico di Git.
Cos’è GitHub e a cosa serve oggi
GitHub è una piattaforma online costruita attorno ai repository Git. Il repository resta il centro del sistema, ma GitHub aggiunge gli strumenti necessari per trasformare il controllo di versione in un processo collaborativo.
Puoi usarlo per un progetto personale con pochi file oppure per un’applicazione sviluppata da molte persone. Il principio rimane lo stesso: il progetto possiede una cronologia, le modifiche possono essere isolate e revisionate e più persone possono contribuire senza dover scambiarsi manualmente cartelle e copie dei file.
Un repository può contenere codice sorgente, file di configurazione, documentazione, test, immagini e altre risorse necessarie al progetto. GitHub mantiene inoltre informazioni che non appartengono direttamente alla cronologia Git, come issue, pull request, discussioni, workflow di automazione e impostazioni di sicurezza.
Questa distinzione è utile perché permette di capire che GitHub usa Git, ma non coincide con Git.
Git e GitHub non sono la stessa cosa
Git è un sistema distribuito di controllo versione. GitHub è una piattaforma che ospita repository Git e costruisce servizi di collaborazione attorno ad essi.
Il controllo versione registra nel tempo le modifiche apportate ai file e permette di recuperare stati precedenti, confrontare cambiamenti e capire come si è evoluto un progetto. Nel modello distribuito usato da Git, un clone contiene normalmente la cronologia del repository e non soltanto una copia degli ultimi file. La documentazione ufficiale di Git sul controllo di versione spiega proprio questa differenza rispetto ai sistemi centralizzati.
Puoi quindi usare Git senza GitHub. Puoi creare un repository sul tuo computer, fare commit, creare branch e mantenere una cronologia completa anche senza connessione a Internet.
Puoi inoltre collegare Git a più repository remoti: GitHub è una delle possibili destinazioni, non una componente obbligatoria del protocollo.
GitHub entra in gioco quando vuoi aggiungere un’infrastruttura condivisa attorno a quel repository: hosting remoto, permessi, pull request, code review, issue, automazioni, ambienti di sviluppo e altri strumenti.
Una metafora può aiutare, purché non venga presa alla lettera: Git gestisce la storia del progetto; GitHub crea uno spazio condiviso intorno a quella storia.
Dal repository al ciclo di vita del software
Il repository è ancora il punto di partenza, ma non è più necessariamente il punto di arrivo.
Immagina un piccolo progetto web. Scrivi il codice, registri le modifiche con Git e lo sincronizzi con GitHub. Da lì puoi:
- aprire un’issue per un bug;
- creare un branch per correggerlo;
- aprire una pull request;
- far revisionare la modifica;
- eseguire automaticamente dei test;
- unire il codice nel branch principale;
- avviare un processo di pubblicazione;
- controllare eventuali problemi nelle dipendenze.
GitHub collega quindi codice, collaborazione, automazione e gestione del progetto.
È proprio questa continuità a renderlo diverso da un semplice spazio cloud per i file.
Per chi è utile GitHub, anche oltre gli sviluppatori
Il pubblico naturale di GitHub resta quello dello sviluppo software, ma i repository possono essere utili anche quando il progetto contiene documentazione, configurazioni, siti statici o materiali che beneficiano del controllo versione.
Un web designer, per esempio, può versionare un progetto HTML/CSS/JavaScript; un tecnico può mantenere script e configurazioni; un autore di software open source può gestire contributi esterni; un team può usare issue e Projects per collegare attività e modifiche al codice.
GitHub non è invece la soluzione giusta per qualsiasi tipo di file. Repository Git pieni di video, backup, archivi o file binari molto pesanti possono diventare difficili da gestire. Il controllo versione è particolarmente efficace quando è possibile confrontare in modo significativo le modifiche ai file.
Come funziona GitHub: repository, commit, branch e pull request
Per capire davvero come funziona GitHub conviene smettere per un momento di pensare alla sua interfaccia e osservare il flusso dei dati.
Il modello più comune è:
repository remoto su GitHub → clone locale → modifica dei file → commit locale → push verso GitHub → eventuale pull request → merge
La parte che spesso genera confusione è che commit e push non sono la stessa operazione.
Repository locale e repository remoto
Un repository locale è quello presente sulla tua macchina. Puoi modificarlo, creare commit e consultarne la cronologia senza che GitHub venga coinvolto.
Un repository remoto è una copia accessibile attraverso una rete e utilizzata per sincronizzare il lavoro. In una configurazione tipica, il repository su GitHub viene associato localmente a un remote chiamato origin.
Quando esegui:
git clone URL_DEL_REPOSITORY
Git crea sul computer un repository locale collegato a quello remoto.
La documentazione ufficiale di Git chiarisce che clone non recupera semplicemente una cartella con i file correnti: crea un repository locale con la storia necessaria per lavorare in modo distribuito.
Questo spiega anche perché Git può continuare a funzionare offline per molte operazioni. Non devi interrogare GitHub ogni volta che vuoi creare un commit o confrontare due versioni locali.
Commit e cronologia: cosa viene realmente versionato
Un commit registra uno stato significativo del progetto nella cronologia Git.
In un normale workflow locale puoi verificare le modifiche:
git status
aggiungere alla staging area ciò che vuoi includere:
git add .
e creare il commit:
git commit -m "Aggiunge il modulo di contatto"
A questo punto hai creato un nuovo commit nel repository locale.
GitHub non ha ancora ricevuto niente.
Per inviare i commit al repository remoto utilizzi push:
git push
Questa separazione è fondamentale.
Salvare un file non significa fare un commit. Fare un commit non significa inviarlo automaticamente a GitHub.
La staging area aggiunge un ulteriore livello di controllo: puoi avere diversi file modificati e decidere quali entreranno nel prossimo commit.
Un buon commit dovrebbe rappresentare una modifica coerente. Se correggi un bug nel form di contatto e contemporaneamente ridisegni completamente il menu, separare le due modifiche può rendere la cronologia molto più leggibile.
Se stai iniziando a programmare per il web, un repository può essere anche un buon modo per osservare l’evoluzione concreta di un piccolo progetto in JavaScript invece di mantenere copie manuali come script-nuovo.js, script-finale.js e script-finale-vero.js.
Branch, merge e pull request
Un branch permette di sviluppare una linea di lavoro senza dover modificare immediatamente il branch su cui si basa la versione principale del progetto.
Supponiamo che main contenga una versione stabile e tu debba aggiungere una ricerca interna.
Puoi creare un branch:
git switch -c feature-ricerca
lavorare sulla funzionalità, creare uno o più commit e poi pubblicare il branch su GitHub:
git push -u origin feature-ricerca
A questo punto GitHub può confrontare feature-ricerca con main.
Ed è qui che entra in gioco la pull request.
Una pull request non è semplicemente un pulsante per effettuare il merge. È uno spazio in cui la modifica può essere descritta, discussa, revisionata e sottoposta a controlli automatici prima di essere integrata.
Il team può commentare singole righe, richiedere correzioni oppure approvare il lavoro.
Se tutto è pronto, la pull request può essere unita al branch di destinazione.
Questo modello riduce la necessità di intervenire direttamente sul branch principale, ma non significa che modificare main sia tecnicamente proibito in ogni situazione. Il workflow dipende dal progetto, dalle dimensioni del team e dalle regole configurate nel repository.
Fork e branch: quando servono e perché non sono la stessa cosa
Fork e branch risolvono problemi differenti.
Un branch appartiene a un repository e crea una linea di sviluppo al suo interno.
Un fork, invece, crea su GitHub un repository collegato a un altro progetto, normalmente sotto un account o un’organizzazione differente.
È particolarmente utile quando vuoi contribuire a un progetto sul quale non hai accesso diretto in scrittura.
Il workflow open source classico è:
- crei un fork;
- cloni il tuo fork;
- crei un branch;
- apporti la modifica;
- esegui push sul tuo fork;
- apri una pull request verso il repository originale.
Dire quindi che “un fork è un branch” sarebbe sbagliato. Il branch separa una linea di sviluppo dentro un repository; il fork separa il repository stesso e consente un modello di collaborazione differente.
Come usare GitHub da zero: dal primo repository al primo push
Per imparare GitHub non serve iniziare con un progetto complesso. È molto più utile creare un repository piccolo e percorrere almeno una volta l’intero ciclo.
La procedura ufficiale per creare un repository GitHub consente di inizializzarlo anche con README, .gitignore e licenza.
Creare l’account e mettere in sicurezza l’accesso
La registrazione dell’account è semplice, ma la sicurezza non dovrebbe essere trattata come una configurazione da rimandare.
Usa un indirizzo email che puoi mantenere nel tempo e configura metodi di recupero affidabili. Per gli account che contribuiscono codice, GitHub ha progressivamente reso obbligatoria l’autenticazione a due fattori per le categorie coinvolte nel programma.
La documentazione GitHub sulla 2FA descrive TOTP, GitHub Mobile, security key e passkey. GitHub raccomanda inoltre di conservare metodi di recupero per evitare di perdere definitivamente l’accesso all’account.
Non limitarti quindi a pensare alla password. Un account che controlla repository privati, token e workflow di deploy può diventare un punto molto sensibile dell’infrastruttura.
Creare un repository e scegliere pubblico o privato
Quando crei un repository devi scegliere prima di tutto proprietario, nome e visibilità.
Un repository pubblico è visibile agli utenti secondo le regole della piattaforma ed è adatto, per esempio, a progetti open source, demo o documentazione che vuoi rendere consultabile.
Un repository privato limita invece l’accesso alle persone autorizzate.
“Privato”, però, non significa che puoi inserirvi indiscriminatamente password e credenziali.
Una chiave API o una password inserita nella cronologia Git può diventare difficile da eliminare completamente e, se viene esposta accidentalmente in seguito, il problema può estendersi anche alla storia del repository.
La regola corretta resta quindi: i segreti non appartengono al codice versionato, indipendentemente dalla visibilità del repository.
README, .gitignore e licenza: cosa aggiungere davvero
Tre file compaiono molto spesso nei repository, ma svolgono funzioni differenti.
README.md spiega il progetto. Dovrebbe permettere a chi arriva nel repository di capire almeno cosa contiene, come iniziare e, nei progetti che lo richiedono, come installarlo o utilizzarlo.
.gitignore indica a Git quali file o pattern non devono essere tracciati. Può escludere cache, file generati, dipendenze installabili nuovamente, impostazioni locali dell’editor e file che non devono entrare nel repository.
Non va però considerato un sistema di sicurezza retroattivo: aggiungere un file a .gitignore dopo aver già commesso un segreto non cancella il segreto dalla cronologia precedente.
La licenza, infine, stabilisce le condizioni secondo cui altri possono usare, modificare o distribuire il progetto. Un repository pubblico non equivale automaticamente a “puoi farne ciò che vuoi”.
Clone, add, commit, push e pull: il workflow essenziale
Supponiamo di aver creato su GitHub un repository inizializzato con un README.
Per lavorare localmente:
git clone URL_DEL_REPOSITORY cd nome-repository
Modifica o aggiungi i file e poi controlla lo stato:
git status
Prepara le modifiche:
git add .
Registra il commit:
git commit -m "Aggiunge la pagina iniziale"
Invialo a GitHub:
git push
Se nel frattempo il repository remoto contiene nuovi commit che devi integrare, entra in gioco pull:
git pull
Questa sequenza sembra banale, ma contiene il modello mentale fondamentale:
modifico → seleziono → registro → sincronizzo
Una volta assimilato, puoi aggiungere branch, pull request e automazioni senza perdere il filo.
Web, GitHub Desktop o terminale: quale strada scegliere all’inizio
GitHub può essere utilizzato in modi diversi.
L’interfaccia web è sufficiente per piccole modifiche, documentazione e molte operazioni amministrative.
GitHub Desktop fornisce una rappresentazione grafica di repository, modifiche, branch e commit ed è una buona soluzione se vuoi imparare il workflow evitando inizialmente gran parte della riga di comando.
Il terminale offre invece un controllo più diretto e corrisponde al modo in cui Git viene utilizzato in numerosi ambienti professionali e automatizzati.
Non è necessario trasformare questa scelta in una battaglia ideologica. L’importante è capire che cosa sta facendo Git, indipendentemente dall’interfaccia utilizzata.
Se GitHub Desktop esegue un commit, sotto l’interfaccia grafica il concetto resta quello del commit Git. Sapere questo ti permette di passare da uno strumento all’altro senza dover reimparare il sistema.
Come collaborare su GitHub senza perdere il controllo del progetto
Il vero salto di qualità arriva quando il repository non è più soltanto tuo.
In un progetto condiviso bisogna coordinare chi modifica cosa, perché lo sta modificando e quando quella modifica può entrare nella versione principale.
GitHub risolve una parte di questo problema collegando branch, issue, pull request, review e regole del repository.
GitHub Flow: dal branch alla revisione
Un workflow semplice può partire da main, creare un branch per ogni modifica significativa e riportare il lavoro su main attraverso una pull request.
Lo schema diventa:
main → nuovo branch → commit → push → pull request → review/test → merge
Non è l’unico workflow Git possibile e non va applicato meccanicamente a qualsiasi progetto. Il vantaggio è che rende visibile l’intenzione della modifica prima che questa entri nella versione di riferimento.
In un team, il branch può quindi rappresentare una feature, una correzione o un’attività specifica.
Il nome fix/login-timeout comunica molto più di branch-2.
Anche i commit dovrebbero avere messaggi che aiutino a capire la modifica. Aggiorna validazione email è più utile di fix se tra sei mesi qualcuno dovrà ricostruire perché quella modifica è stata fatta.
Issues, pull request e code review
Le Issues rappresentano problemi, richieste, idee o attività da seguire.
Una issue può descrivere:
- un bug;
- una funzionalità;
- un miglioramento;
- una richiesta di documentazione;
- un’attività tecnica.
La pull request rappresenta invece una proposta concreta di modifica al repository.
Collegare una pull request alla relativa issue consente di ricostruire il percorso:
problema → discussione → implementazione → revisione → soluzione
Durante la code review, i collaboratori possono commentare il diff, proporre modifiche e bloccare il merge quando le regole del repository richiedono determinate approvazioni.
La review non serve soltanto a “trovare errori”. Può servire anche a condividere conoscenza sul codice, verificare l’aderenza alle decisioni del progetto e rendere visibili modifiche che altrimenti sarebbero comprensibili soltanto all’autore.
Projects e Discussions per organizzare il lavoro
GitHub Projects aggiunge una vista organizzativa alle attività. Issue e pull request possono essere gestite in viste e workflow utili a seguire stato, priorità o altre proprietà del lavoro.
Discussions, quando abilitate nel repository, servono invece a conversazioni che non devono necessariamente diventare issue operative: domande, idee, proposte o discussioni della community.
La distinzione evita di usare la sezione Issues come contenitore di qualsiasi conversazione.
Per un progetto piccolo può essere superfluo. Per un repository con molte persone, separare discussione, task e modifica del codice riduce notevolmente il rumore.
CONTRIBUTING e documentazione nei progetti condivisi
Quando un progetto inizia a ricevere contributi, documentare il workflow evita che ogni nuovo collaboratore debba imparare le regole per tentativi.
Un CONTRIBUTING.md può spiegare:
- come aprire una issue;
- come preparare una pull request;
- convenzioni per branch e commit;
- standard di codice;
- procedure di test;
- requisiti per accettare una modifica.
Il valore non sta nell’avere il file in sé. Sta nel rendere esplicite le aspettative del progetto.
Un repository con documentazione minima ma precisa è spesso più facile da mantenere di uno pieno di regole implicite conosciute solo dal team storico.
GitHub Actions, Codespaces e Pages: cosa aggiungono al repository
Una volta compreso il workflow Git, GitHub può iniziare a fare molto più che conservare la copia remota del progetto.
Tre strumenti chiariscono bene questa evoluzione: Actions automatizza processi, Codespaces fornisce ambienti di sviluppo nel cloud e Pages pubblica siti statici direttamente da un repository.
GitHub Actions per test, build e deploy
GitHub Actions permette di definire workflow automatici collegati agli eventi del repository.
Un workflow è descritto attraverso file YAML nella directory .github/workflows.
Può essere eseguito, per esempio:
- dopo un push;
- quando viene aperta una pull request;
- in seguito alla pubblicazione di una release;
- manualmente;
- secondo una pianificazione.
La documentazione ufficiale di GitHub Actions lo descrive come una piattaforma per automatizzare anche pipeline di build, test e deployment.
Un caso semplice è l’esecuzione automatica dei test a ogni pull request.
Invece di sperare che ogni sviluppatore li abbia eseguiti correttamente sul proprio computer, il repository può avviare lo stesso processo in un ambiente controllato. Se il test fallisce, la pull request può mostrare il problema prima del merge.
Lo stesso principio può essere esteso al deploy.
Questo non significa, però, che GitHub Actions renda automaticamente corretta una pipeline. I workflow hanno permessi, token, dipendenze e accesso a risorse esterne: una configurazione poco attenta può introdurre rischi.
L’automazione elimina lavoro ripetitivo; non elimina la necessità di progettare quel lavoro correttamente.
Codespaces e github.dev per lavorare dal browser
GitHub Codespaces porta l’ambiente di sviluppo nel cloud.
Un codespace viene eseguito in un ambiente remoto configurabile associato al repository. Puoi aprirlo dal browser oppure collegarti attraverso Visual Studio Code e lavorare con terminale, Git, debugging e porte inoltrate.
La documentazione di GitHub Codespaces evidenzia uno dei vantaggi più interessanti: il repository può definire un ambiente ripetibile, riducendo le differenze fra le configurazioni locali dei collaboratori.
Questo diventa utile quando un progetto richiede runtime, dipendenze o strumenti specifici.
Il vantaggio pratico non è semplicemente “programmare dal browser”. È poter dire:
questo progetto può fornire anche il suo ambiente di sviluppo.
github.dev risponde invece a un’esigenza più leggera: permette di aprire una rappresentazione del repository in un editor web basato sull’esperienza di Visual Studio Code, utile soprattutto per navigazione e modifiche che non richiedono un ambiente remoto completo.
Codespaces e github.dev non vanno quindi confusi. Il primo fornisce risorse di calcolo e un vero ambiente remoto; il secondo è principalmente un’esperienza di editing web.
GitHub Pages per siti statici e documentazione
GitHub Pages è un servizio di hosting per siti statici collegato ai repository.
Può pubblicare HTML, CSS e JavaScript direttamente da GitHub, eventualmente passando attraverso un processo di build. La documentazione ufficiale di GitHub Pages conferma inoltre la possibilità di utilizzare un dominio personalizzato.
È una buona soluzione per:
- documentazione;
- portfolio;
- demo;
- siti di progetto;
- pagine statiche;
- siti generati da static site generator compatibili con il workflow scelto.
Se non hai ancora chiaro cosa costituisce una pagina web statica, puoi partire dalla nostra guida su HTML e struttura delle pagine web.
Il limite da ricordare è altrettanto importante: GitHub Pages non è un hosting applicativo generico.
Non sostituisce un server su cui devi eseguire liberamente PHP, database, servizi persistenti o applicazioni server-side tradizionali.
Per un sito o un’applicazione ospitati su un server esterno puoi invece usare una pipeline di deploy, oppure in determinati workflow trasferire file attraverso protocolli come SFTP.
Se il progetto richiede pieno controllo sull’ambiente server, il problema diventa diverso da GitHub Pages e può avere senso valutare un hosting VPS o un’altra infrastruttura adeguata all’applicazione.
Sicurezza su GitHub: account, repository e segreti
GitHub può diventare un punto centrale del processo di sviluppo. Proprio per questo la sicurezza non va limitata alla domanda “il repository è pubblico o privato?”.
Bisogna distinguere almeno tre superfici:
account → accesso al repository → contenuto e pipeline del repository
Proteggere soltanto una di queste lascia aperte le altre.
Repository pubblico e privato: cosa cambia davvero
La visibilità determina chi può vedere il repository secondo le impostazioni e le autorizzazioni applicabili.
Un repository privato è quindi necessario quando il codice non deve essere pubblicamente accessibile, ma non sostituisce una corretta gestione dei permessi.
In un’organizzazione è importante concedere agli utenti soltanto il livello di accesso necessario e rimuovere accessi non più utili.
La stessa prudenza vale per applicazioni, token, chiavi SSH e integrazioni che possono operare sul repository.
Privato significa controllo dell’accesso, non invulnerabilità.
2FA, passkey e protezione dell’account
L’account GitHub può autorizzare modifiche al codice, accesso a repository privati e operazioni sensibili. Un account compromesso può quindi produrre conseguenze molto più serie della semplice perdita di un profilo.
GitHub supporta diversi metodi di autenticazione e recupero e documenta anche l’uso delle passkey. La configurazione ufficiale della 2FA e delle passkey chiarisce inoltre che una passkey può soddisfare password e secondo fattore nelle condizioni previste.
La parte spesso dimenticata sono i recovery code.
Attivare un metodo forte e poi perdere l’unico dispositivo necessario per usarlo può trasformare una misura di sicurezza in un problema di accesso. Configurazione e recovery devono essere pensati insieme.
Perché password, token e file .env non devono finire nei commit
Una delle regole più importanti quando utilizzi Git è molto semplice:
non committare segreti.
Il file .env, per esempio, può contenere password del database, chiavi API, token o altre informazioni che servono all’applicazione ma che non dovrebbero entrare nel repository.
Aggiungerlo a .gitignore prima del primo commit è una delle difese basilari.
Se però un segreto è già stato committato, cancellare il file dal commit successivo non basta necessariamente: potrebbe continuare a essere disponibile nella cronologia precedente.
In caso di esposizione devi valutare la revoca o rotazione della credenziale, non soltanto la rimozione dal repository.
Lo stesso principio vale per GitHub Actions. Le credenziali necessarie ai workflow devono essere gestite attraverso i meccanismi previsti per secrets e permissions, non scritte direttamente nei file YAML.
Dependabot e strumenti di sicurezza: cosa fanno e quali limiti hanno
GitHub integra diverse funzionalità di sicurezza, ma la loro disponibilità dipende dal tipo di repository, dal piano e dagli eventuali prodotti di sicurezza attivati.
La panoramica ufficiale delle funzionalità di sicurezza GitHub distingue chiaramente le funzioni disponibili sui diversi piani da quelle collegate a GitHub Secret Protection e GitHub Code Security.
Dependabot può segnalare dipendenze vulnerabili e, in determinati workflow, proporre aggiornamenti.
Secret scanning cerca credenziali e altri segreti riconoscibili.
Code scanning analizza il codice alla ricerca di classi di vulnerabilità e problemi supportati.
Sono strumenti importanti, ma non vanno interpretati come una certificazione automatica di sicurezza.
Un progetto può non produrre alert e contenere comunque vulnerabilità logiche, errori di autorizzazione, configurazioni insicure o rischi che uno scanner non è in grado di identificare.
Automated security checks migliorano la copertura; non sostituiscono progettazione, review e test.
GitHub e l’intelligenza artificiale: Copilot e coding agent
L’integrazione dell’intelligenza artificiale sta modificando GitHub più profondamente di quanto faccia pensare la semplice generazione di codice nell’editor.
Il cambiamento più interessante riguarda il passaggio da un assistente che suggerisce codice mentre lavori a agenti ai quali puoi delegare attività sul repository.
È però importante distinguere le diverse superfici e non descrivere come universalmente disponibile ciò che dipende da piano, policy o stato di preview.
Copilot nel repository, nella review e nel workflow di sviluppo
GitHub Copilot non è più confinato alle sole completions nell’editor.
Le funzionalità Copilot comprendono esperienze di chat, review e modalità agentiche che possono interagire con il contesto del progetto. La disponibilità delle singole funzioni e i limiti dipendono dal piano e dalle policy applicate all’account o all’organizzazione.
Per questo una guida a GitHub non dovrebbe trasformarsi in una lista di tutte le feature Copilot: cambiano più velocemente dei concetti fondamentali di repository, branch e pull request.
Il modello mentale utile è piuttosto questo:
GitHub conserva il contesto operativo del progetto; gli strumenti AI possono lavorare sempre più direttamente dentro quel contesto.
Questo rende ancora più importante avere repository ordinati, istruzioni comprensibili, test e workflow affidabili. Un agente che modifica codice non elimina la necessità di sapere come verificare la modifica.
Copilot cloud agent: cosa cambia rispetto all’assistente nell’IDE
Un coding agent può ricevere un’attività e lavorarci in modo più autonomo rispetto alla classica assistenza interattiva dell’IDE.
La documentazione sul Copilot cloud agent descrive un workflow in cui l’agente può analizzare il repository, preparare un piano, modificare il codice su un branch e lasciare il risultato pronto per la revisione dell’utente.
La differenza concettuale è significativa.
Con un assistente tradizionale lavori sul codice e chiedi aiuto.
Con un agente puoi invece delegare un task, ricevere una modifica e valutarla come valuteresti il contributo prodotto da un altro partecipante al workflow.
Non significa che l’output debba essere accettato automaticamente. Branch, diff, test e pull request diventano semmai ancora più importanti perché costituiscono il livello di controllo tra lavoro autonomo e codice integrato.
Codex e Claude su GitHub: cosa è disponibile e cosa è ancora in preview
GitHub supporta anche coding agent di terze parti integrati nel proprio workflow.
La documentazione GitHub sui third-party coding agents indica attualmente OpenAI Codex e Anthropic Claude tra gli agenti supportati e qualifica questa integrazione come public preview. È inoltre collegata ai piani Copilot a pagamento e alle relative policy.
Un agente può essere incaricato da superfici come issue o strumenti dedicati, lavorare alla modifica e produrre una pull request da revisionare.
Qui la distinzione fra “disponibile” e “stabile” conta.
Public preview significa che la funzione esiste e può essere utilizzata nelle condizioni indicate, ma può ancora cambiare.
Per questo eviterei di costruire il tuo modo di usare GitHub attorno a una specifica interfaccia agentica. È molto più solido imparare bene repository, branch, pull request, test e review: qualunque agente utilizzerai dovrà comunque inserirsi in quel modello.
GitHub è gratuito? Piani e limiti da conoscere
Sì, GitHub può essere utilizzato gratuitamente. GitHub Free permette di creare repository pubblici e privati e include una serie di funzionalità e quote.
Questo non significa però che qualsiasi servizio collegato a GitHub sia sempre gratuito e senza limiti.
La pagina ufficiale dei piani GitHub distingue il piano Free dai piani e prodotti a pagamento e specifica le quote previste per servizi come Actions e Codespaces.
Cosa puoi fare con GitHub Free
Per imparare GitHub, mantenere progetti personali, lavorare su repository open source e gestire molti normali workflow di sviluppo, il piano gratuito è già sufficiente per iniziare.
Sono disponibili repository pubblici e privati senza la necessità di acquistare immediatamente un piano Team o Enterprise.
La presenza di un piano Free è importante anche didatticamente: non devi scegliere una configurazione enterprise per imparare repository, commit, branch, fork o pull request.
Sono i concetti fondamentali che conviene imparare per primi.
Quando entrano in gioco piani a pagamento e consumo a uso
I costi diventano rilevanti quando hai esigenze organizzative, di sicurezza, supporto, AI oppure utilizzi servizi misurati oltre le quote incluse.
GitHub distingue infatti fra:
- piano dell’account o dell’organizzazione;
- prodotti e add-on;
- utilizzo misurato di determinati servizi.
Actions e Codespaces sono esempi importanti perché consumano risorse di calcolo o storage.
Lo stesso vale per alcune funzioni AI.
Per questo eviterei di decidere sulla base di una tabella prezzi copiata mesi prima. Se una funzionalità può incidere sui costi del progetto, controlla sempre pricing e billing ufficiali nel momento in cui la attivi.
Il principio vale soprattutto per workflow automatici: un’azione che viene eseguita raramente in un repository personale e una pipeline attiva continuamente in un’organizzazione possono avere profili di utilizzo completamente diversi.
Conclusione
Imparare GitHub diventa molto più semplice quando smetti di memorizzare feature e parti dal suo meccanismo fondamentale.
Git registra la storia del progetto. Il repository locale è il tuo ambiente di lavoro. GitHub aggiunge il repository remoto e gli strumenti necessari per collaborare, revisionare, automatizzare e gestire ciò che accade intorno al codice.
Da questo modello derivano quasi tutti i concetti importanti.
Il commit registra una modifica. Il push la sincronizza con il remote. Il branch isola una linea di lavoro. La pull request trasforma quella linea di lavoro in una proposta revisionabile. Issues e Projects collegano il codice alle attività. Actions automatizza processi. Codespaces sposta l’ambiente di sviluppo nel cloud. Pages può pubblicare un progetto statico. Gli strumenti di sicurezza e gli agenti AI aggiungono altri livelli, ma non sostituiscono le fondamenta.
Se parti da zero, quindi, non cercare di imparare contemporaneamente ogni funzione di GitHub.
Crea un piccolo repository, clonalo, modifica un file, fai un commit, esegui il push e poi prova lo stesso percorso usando un branch e una pull request.
Quando quel ciclo ti risulterà naturale, il resto della piattaforma smetterà di apparire come un insieme di strumenti separati e inizierà a funzionare come un unico workflow.