Cos’è GitHub e come usarlo

In questa guida scoprirai cos’è e come funziona GitHub; com’è nato intorno a Git diventando qualcosa di molto diverso: una piattaforma che serve a eseguire il controllo di versione ma anche a gestire i progetti e condividerli in cloud; a comunicare all’interno dei team e con altri utenti.

Qui vedremo come usare GitHub passo passo sperimentando le sue principali funzionalità e daremo un’occhiata a quanto offre a chi avrà voglia di conoscerlo meglio. 

Cos’è GitHub

GitHub è una piattaforma web pensata per ospitare progetti basati su Git, con funzionalità per la gestione del lavoro e la collaborazione. 

GitHub funziona come un archivio online in cui è possibile conservare copie di backup del proprio lavoro ma anche modificarlo in sicurezza, e tornare alle versioni precedenti ogni volta che ce n’è bisogno. 

In più la piattaforma permette di collaborare sui progetti in modo ordinato e trasparente, grazie agli strumenti per documentare e pianificare il lavoro, segnalare i problemi e testare le modifiche prima di renderle definitive. 

GitHub è usato soprattutto per ospitare, gestire e condividere codice sorgente, una sorta di Google Drive dove però si possono caricare solo cartelle inizializzate come repository Git.

Ma GitHub è molto più di servizio di cloud storage per progetti software basati su Git: oltre agli strumenti per tracciare le modifiche ai file e pianificare il lavoro, offre funzionalità da social network come la possibilità di seguire altri sviluppatori e repository e collaborare in modo interattivo; tanto che intorno alla piattaforma è cresciuta una vera e propria community. 

GitHub rende accessibile Git anche a chi non ha competenze tecniche avanzate grazie all’interfaccia intuitiva e amichevole ed è usato anche per gestire progetti che non riguardano il codice.

Come nasce GitHub

Probabilmente avrai già capito che GitHub è un servizio costruito a partire da Git. Ma cos’è Git?

Git è uno strumento per il controllo versione creato nel 2005 da Linus Torvalds per supportare lo sviluppo del kernel Linux. 

GitHub invece è stato lanciato nel 2008 per facilitare l’uso di Git e la collaborazione online e in pochi anni è diventato la piattaforma di riferimento per la gestione dei progetti software, introducendo funzionalità, come le pull request, che hanno trasformato il modo in cui i team creano progetti open source. 

Nel 2018 è stato acquisito da Microsoft, che ha continuato a svilupparlo e a promuoverne l’uso nel mondo open source e aziendale.

Nel 2025 GitHub è ancora la piattaforma online più usata dai programmatori a livello mondiale: secondo i dati ufficiali, ospita infatti oltre 150 milioni di sviluppatori e più di 420 milioni di repository.

Differenze tra GitHub e Git 

Viste tutte le cose in comune tra Git e GitHub, a cominciare dal nome, è facile confonderli; per chiarire, capiamo prima cos’è Git.

Cos’è Git?

Git è un sistema di controllo versione, cioè uno strumento che tiene traccia di tutte le modifiche fatte a un progetto salvandole in un archivio locale. Oltre a creare una cronologia dettagliata delle modifiche, Git permette di lavorare in parallelo su diverse versioni del progetto e di tornare indietro in caso di errore. 

Inoltre Git è un sistema distribuito, cioè permette a ogni sviluppatore di scrivere codice su una copia autonoma dei file. 

Il software è pensato per essere usato da riga di comando – nonostante oggi esistano interfacce visive per Git –, anche offline, in quanto le operazioni principali si svolgono in locale.

Per tutti questi motivi oggi Git è considerato uno standard per gestire il codice in modo efficiente e sicuro. 

Perché GitHub e Git sono diversi

La differenza principale tra Git e GitHub è che Git è uno strumento, mentre GitHub è un servizio. 

Git è un software installabile sul pc, che serve a creare e gestire archivi locali. GitHub è un sito web con un’infrastruttura cloud che ospita archivi remoti e permette di collaborare con altri utenti su progetti condivisi.

Poiché GitHub è una piattaforma online basata su Git, Git si può usare senza GitHub mentre GitHub non funziona senza Git.

Infatti GitHub è un remote per Git – non l’unico – e diventa necessario solo quando si vogliono condividere online i cambiamenti fatti in locale.

Quando si può usare solo Git, e quando conviene usare anche GitHub?

Git può essere sufficiente se si lavora da soli, senza la necessità di condividere codice o collaborare. In questi casi si può creare un repository (archivio) Git sul proprio computer e usarlo come diario delle modifiche.

GitHub e strumenti analoghi diventano indispensabili per lavorare in gruppo, mostrare un progetto a potenziali clienti, o a colleghi per avere un feedback, e poter contare su un backup remoto.

Se volessi creare uno script Python per automatizzare il backup dei tuoi documenti, ti basterebbe Git. Se a un certo punto ti andasse di distribuirlo come software open source, ti servirebbe anche GitHub. 

In un certo senso, usare Git senza GitHub è come scrivere un libro offline sul proprio pc; mentre usare anche GitHub è come caricare il file del libro in cloud su un documento condiviso che altri autori possono vedere, commentare e modificare in tempo reale.

A cosa serve GitHub

GitHub serve a fare cose molto diverse che vanno dal controllo versione dei file alla collaborazione efficace e al networking sino alla documentazione dei progetti alla creazione di portfolio per sviluppatori; in più è un hosting per progetti open source e siti statici.

Versioning del codice

Grazie a GitHub ogni versione dei file può essere registrata, commentata, ordinata cronologicamente e recuperata all’occorrenza. La cronologia completa del progetto aiuta a capire come si è evoluto un progetto, correggere errori, confrontare versioni, lavorare su funzionalità diverse in contemporanea e sperimentare senza paura.

Collaborazione efficace

Il controllo di versione distribuito è particolarmente utile per i team perché permette a più persone di lavorare sullo stesso progetto senza conflitti e senza rischiare di sovrascrivere il lavoro altrui. Inoltre si sa sempre chi ha fatto cosa e quando.

GitHub offre anche funzionalità per proporre modifiche, discuterle e approvarle in modo strutturato, così come per pianificare e assegnare i task.

Hosting di progetti open source e siti statici

La piattaforma ospita migliaia di progetti pubblici, accessibili a chiunque voglia contribuire, e questo favorisce il miglioramento continuo del codice. D’altra parte collaborare a un progetto open source su GitHub è un ottimo modo per imparare, ma anche per costruire relazioni con altri sviluppatori. Da ricordare che GitHub può fare da hosting anche a siti statici creati a partire dai suoi repository.

Portfolio per sviluppatori

Un profilo GitHub curato può essere una vetrina professionale per chi si occupa di codice e può fare la differenza quando si cerca lavoro – sempre più aziende lo considerano parte integrante del curriculum di uno sviluppatore. Inoltre su GitHub anche i programmatori freelance possono attirare l’attenzione e guadagnare collaborazioni a pagamento.

Documentazione tecnica

GitHub permette di creare e conservare la documentazione tecnica su file README.md o intere wiki, rendendo questa attività parte integrante del flusso di lavoro. Così la piattaforma facilita la comunicazione tra i collaboratori e aiuta gli utenti a capire come installare e usare il software o contribuire al suo sviluppo. 

Gestione di progetti non informatici

Anche se è stato creato per il codice, GitHub è sempre più usato per progetti creativi o tecnici che non riguardano lo sviluppo web o software. Gli scrittori possono usarlo per collaborare sui testi, i designer per registrare versioni di file SVG o layout, i data analyst per gestire dataset. 

D’altra parte un repository Git può contenere file di qualsiasi tipo, anche se è buona norma evitare quelli troppo pesanti. È comunque possibile escludere dal versioning solo alcuni documenti contenuti nella cartella.

Come funziona GitHub

Non puoi sapere come funziona GitHub se non conosci tre concetti chiave: repository, commit e branch.

Le basi: repository, commit e branch

Un repository (o repo) è l’archivio dove si conservano i file e la cronologia delle modifiche: comprende codice, file di configurazione, documentazione e tutto ciò che serve per far funzionare l’applicazione. Esistono repo pubblici e privati.

I branch sono rami paralleli del progetto che servono a lavorare su nuove funzionalità o proporre varianti a quelle in uso senza toccare la versione principale – che è anch’essa un branch, oggi di solito chiamato main, in passato master. 

Le modifiche a un repo – in qualunque ramo – possono essere registrate coi commit, sorta di istantanee che fissano cosa è stato cambiato, da chi e quando, e costituiscono la cronologia del progetto. Ogni commit è accompagnato da un messaggio descrittivo e identificato in modo univoco da un codice hash.

Un’occhiata alle funzionalità principali

Quando lo sviluppo su un ramo secondario è terminato, lo si può unire a quello principale con una pull request, cioè una proposta di modifica al codice che dovrà essere valutata dagli amministratori del repo.

Se la PR viene accettata, ci sarà un merge e le due versioni del progetto si fonderanno in una sola. 

Il push è invece l’operazione con cui si inviano al repository remoto su GitHub le modifiche fatte in locale – come la creazione di file, il loro aggiornamento e i commit.

Issues è una funzionalità per la collaborazione che consente di segnalare bug, proporre miglioramenti e discutere idee.

A grandi linee, il ciclo di vita di un progetto su GitHub si svolge così:

1. creazione del repository per ospitare il codice
2. creazione di branch per sviluppo di alternative o nuove funzionalità
3. modifiche al codice e salvataggio tramite commit
4. apertura di una pull request per proporre le modifiche al branch principale
5. revisione e discussione delle modifiche con il team, seguita dalla fusione (merge) nel branch principale.

Ma non è tutto qui.

Altre funzionalità

GitHub non si limita a portare online le funzionalità di Git, ma offre una serie di strumenti aggiuntivi.

Con le Actions è possibile automatizzare attività ripetitive: ad esempio impostare test del codice a ogni nuovo commit o la pubblicazione automatica di documentazione o siti web.

I Projects di GitHub sono invece spazi che servono a gestire il lavoro su uno o più repository in modo collaborativo e visivo, grazie a tabelloni in stile kanban.

Le GitHub Pages permettono di generare siti web statici dai repository GitHub – a partire da file HTML, CSS, JavaScript o tramite generatori statici come Jekyll – e fanno da hosting.

GitHub offre anche varie funzionalità ‘social’, ad esempio gli utenti possono seguire altri profili e progetti, commentare su issue e pull request e partecipare a discussioni pubbliche. 

Grazie a PR, issue e fork è possibile proporre modifiche a repository altrui e ricevere feedback. Si possono invitare altri utenti a valutare i propri progetti o collaborare o coinvolgerli nelle conversazioni con le mention (tag). 

Integrazione di GitHub con altri strumenti

GitHub si integra facilmente con moltissimi strumenti esterni, come editor di codice (Visual Studio Code, Atom), servizi cloud (AWS, Netlify), tool di project management (Trello, Jira) o app di chat e notifiche (Slack, Discord).

Questo permette di far convivere in un unico flusso codice, comunicazioni, task e automazioni e di personalizzare al massimo l’ambiente di lavoro.

Come usare GitHub

Per iniziare a usare GitHub basta creare un account gratuito sulla piattaforma.

Non hai bisogno di conoscere bene Git per fare i primi passi su GitHub perché puoi svolgere molte operazioni dall’interfaccia web; in più in questa guida ti spiegherò come procedere.

GitHub può essere usato da riga di comando o attraverso l’interfaccia grafica GitHub Desktop, che non richiede la conoscenza del codice e va installata sul pc. Qui non la useremo e ci concentreremo sui comandi di base da terminale, per capire la logica di Github (e di Git).

Prima di tutto devi installare Git e creare un account GitHub gratuito. Se hai già fatto queste cose, salta pure a Nuovo repository su GitHub.

Installare Git

Per installare Git sul tuo computer devi prima di tutto scaricarlo gratis dal sito ufficiale.

Su Linux, puoi installare Git tramite il gestore pacchetti della tua distribuzione dopo averlo scaricato da questa pagina.

Qui puoi scaricare la versione per Mac.

Qui quella per Windows.

Se sei alle prime armi, durante l’installazione su Windows o Mac, accetta tutte le impostazioni di default. 

Creare un account GitHub

Installato Git, crea un account GitHub andando sul sito. Ti verrà chiesto di risolvere un puzzle visivo per dimostrare che sei un essere umano e verificare le email, poi potrai accedere.

Eccoci nella dashboard di GitHub, che ci dà un’idea di tutto quello che possiamo fare sulla piattaforma. Qui possiamo creare il nostro primo repository o esplorare quelli condivisi e vedere quelli in trend.

Inoltre troviamo i tutorial per iniziare a usare github, imparare a programmare con GitHub Copilot, creare un sito con GitHub Pages o un workflow di GitHub Actions.

Per presentarti alla community puoi modificare il file README generato in automatico dentro un repository chiamato ‘nomeutente’.

E se ti interessano le funzioni social, puoi scoprirle in questa pagina. 

Nuovo repository su GitHub

È ora di iniziare a sporcarci le mani e creare insieme il tuo primo repository su GitHub.

La dashboard contiene diversi pulsanti per aggiungere un repository ma in qualunque pagina puoi trovare nella barra di strumenti orizzontale il pulsante verde ‘+’ e selezionare la prima voce.

Ti troverai nella schermata Create a new repository, dove dovrai inserire un nome per l’archivio e, a tua scelta, anche una descrizione breve – nell’apposito campo. 

Cosa importante: devi decidere se il repository è pubblico – visibile a tutti ma modificabile solo da chi autorizzi –, o privato – nel qual caso sceglierai tu chi lo può vedere e modificare.

Infine ci sono alcune impostazioni facoltative ma raccomandate.

A tua scelta puoi aggiungere un file README per descrivere il progetto; in realtà se non lo fai ora dovrai occupartene a breve perché non può esistere un repository vuoto, e per convenzione lo si inaugura con un README o un TXT.

Il comando .gitignore ti permette di selezionare formati di file da non tracciare da un menù a tendina che ne contiene diverse decine, tra cui Android, Prestashop, Magento, WordPress, C++. 

Infine puoi scegliere da un menù una licenza standard, ad esempio GNU v.3.0.

Definite le impostazioni, fai clic su Crea repository in basso a sinistra e sarai dentro il tuo nuovo repo.

A questo punto GitHub invita chi ha già esperienza a iniziare subito e creare un nuovo file o importarne uno.

Mentre a chi è alle prime armi suggerisce di partire:

• creando il repository da zero (…or create a new repository on the command line)
• oppure caricando un repository esistente dal pc (…or push an existing repository from the command line)

Entrambe le strade richiedono l’inserimento di istruzioni dalla riga di comando – quelle che vedi su GitHub o delle loro varianti.

Ora vediamo passo passo come usarle e cosa significano.

Iniziamo con la seconda modalità – l’importazione di un repository esistente – perché è più facile capire come funziona GitHub se si parte da Git, in locale. 

Caricare un repository esistente (dal pc)

Come si fa a caricare su GitHub un repository locale?

Ovviamente ti serve un repository sul tuo computer, cioè una qualunque cartella inizializzata con Git. 

Se non lo hai, segui i passaggi e crealo da zero. 

Se invece la cartella che vuoi tracciare con Git esiste già sul pc, puoi saltare a Inizializzare la cartella.

Creare la cartella

Devi innanzitutto spostarti nella directory in cui vuoi posizionare il repo, con il comando cd (change directory):

cd percorsocartella

Se ti trovi già nel desktop e vuoi entrare in una cartella che si trova lì, ti basta digitare:

cd nomecartella

In ogni caso il modo più semplice è digitare solo ‘cd’, premere spazio e trascinare la cartella dentro il terminale.

Una volta che sei nella posizione giusta, puoi creare la cartella che diventerà il repository, eseguendo il comando mkdir (make directory):

mkdir nomecartella

Per poi entrare nella cartella con:

cd nomecartella

Ad esempio, qui mi sono spostata in Desktop > Progetti-Git, ho creato la cartella ‘secondo-repository’ e ci sono entrata con Git:

A questo punto la nuova cartella dovrebbe essere comparsa nella posizione che hai scelto.

Inizializzare la cartella

Se la cartella esiste già, devi inizializzarla come repository, cioè farla diventare un nuovo repository Git locale.

Prima di tutto assicurati di essere al suo interno, o spostati lì così:

cd percorsocartella

Per inizializzare la cartella, esegui:

git init

Abbiamo visto che GitHub e Git non tengono traccia delle cartelle vuote, per cui si usa inserire un apposito file con un editor di testo oppure con il comando touch di Git. Ad esempio io ho creato file-vuoto.txt, digitando: 

touch file-vuoto.txt

Ora Git vede il file ma non ne terrà traccia finché non gli diremo esplicitamente di aggiungerlo al controllo di versione con:

git add .

Dove il punto serve ad aggiungere tutti i file presenti nel repository locale.

In qualsiasi momento puoi verificare se ci sono file che non vengono ancora tracciati eseguendo:

git status

Come vedi, Git mi segnala che c’è da fare un commit per registrare la creazione del file .txt.

 Se non l’avessi già aggiunto al controllo di versione, leggerei anche qualcosa tipo:

Untracked files:

 (use "git add <file>..." to include in what will be committed)

file-vuoto.txt

nothing added to commit but untracked files present (use "git add" to track)

In sostanza sarei invitata ad aggiungere il file perché possa essere incluso nel prossimo commit. 

Eseguire il primo commit 

È arrivato il momento di fare il primo commit per registrare la versione iniziale del progetto. 

Il comando è:

git commit -m "messaggio che spieghi a cosa corrisponde il commit"

Tieni conto che i commit restano visibili nel repository per sempre – si possono cancellare ma non è consigliabile – e che il messaggio è una nota che aiuta a tenere traccia dell’evoluzione del progetto. Se un giorno dovessi decidere di renderlo pubblico, altre persone potrebbero aver bisogno di capire cosa significano i messaggi che hai lasciato, e probabilmente tra qualche anno anche a te farà comodo che siano comprensibili.

Esempi di messaggi utili, che rendono la cronologia delle versioni comprensibile sono: risolto bug X, aggiunta nuova funzione Y, ecc.

Ora non ti resta che importare la cartella su GitHub.

Dopodiché usa i comandi che GitHub suggerisce nella sezione ‘…or push an existing repository from the command line’.

Per collegare il repository locale al repository su GitHub attraverso l’URL:

git remote add origin https://github.com/nomeutente/nomerepository.git

Per rinominare il branch in main:

git branch -M main

Per inviare il contenuto del tuo branch main a ‘origin’ su GitHub:

git push -u origin main

Inserendo il tuo nome utente GitHub e il nome del repository remoto al posto dei dati generici.

Se è la prima volta che usi GitHub in locale, ti verrà chiesto di eseguire l’accesso.

Creare un repository GitHub da zero

Questo è il caso in cui non esistono ancora né il repository remoto né quello locale.

Per creare un repository GitHub da zero, puoi creare una cartella sul tuo pc con Git, chiamandola per praticità come il repository remoto.

Apri la riga di comando su Mac e Linux oppure Git Bash su Windows, e inserisci le istruzioni: 

echo "# nome-repository" >> README.md

git init

git add README.md

git commit -m "first commit"

git branch -M main

git remote add origin https://github.com/nomeutente/nomerepository.git

git push -u origin main

Assicurati di andare a capo tra una e l’altra e sostituisci i tuoi dati a quelli generici per nome utente e nome repository. 

Se anche a te piace capire sempre a fondo quel che stai facendo, eccoti il significato di ogni singolo comando che devi inserire.

echo “# nome-repository” >> README.md – crea un file chiamato README.md (se non esiste già) e ci scrive dentro il testo il nome del repo.

git init – inizializza un nuovo repository Git locale nella cartella corrente.

git add README.md – aggiunge il file README.md all’area di staging, cioè dice a Git di includerlo nel prossimo commit.

git commit -m “first commit” – esegue il primo commit – cioè salva lo stato attuale del progetto – associandogli il messaggio “first commit” (ma potresti inserire anche una frase diversa). 

git branch -M main – rinomina il branch corrente in main perché il branch principale oggi si chiama così per convenzione, e usando una terminologia coerente si evitano errori.

git remote add origin https://github.com/nomeutente/nomerepository.git – collega il repository Git locale a quello remoto; in più ‘origin’ diventa una scorciatoia per il repository su GitHub.

git push -u origin main – invia il contenuto del branch main dal tuo computer al repository su GitHub.

Dopo aver eseguito i comandi ti verrà richiesto di connettere il tuo account GitHub via browser inserendo le credenziali o con un codice ricevuto via mail.

Per procedere devi autorizzare Git Credential Manager. 

D’ora in poi, ogni volta che farai delle modifiche in locale ed eseguirai un commit, dovrai inviarle anche a GitHub se vuoi che i repository locale e remoto restino sincronizzati.

Creare un nuovo branch

Come si crea un nuovo branch su GitHub?

Come sempre, ci sono due opzioni: sfruttare il sito oppure la riga di comando.

Nuovo branch da GitHub

Su GitHub, entra nel repository che vuoi modificare, selezionandolo dai Top repositories o cercandolo con la barra se non è visibile. 

Una volta dentro, vai sul pulsante che mostra il branch attivo – probabilmente main – e apri il menù a tendina.

Se inserisci un nome di branch non presente, appare il pulsante Create new branch from main, e dopo averlo selezionato ti troverai nel nuovo ramo, che sarà un clone del main. 

Con lo stesso procedimento puoi creare nuovi branch anche a partire da branch secondari: utile quando hai in mente delle modifiche ma vuoi studiarne più versioni. L’unica differenza è che, in questo caso, nel menù devi portarti sul ramo secondario prima di creare il nuovo.

Nuovo branch da riga di comando

Se stai lavorando in locale con Git esegui: 

git checkout -b nomebranch

Così crei il nuovo branch e ti sposti lì dentro, lasciando quello precedente (checkout).

Inviare un branch a GitHub

Per inviare a GitHub le modifiche fatte sul nuovo branch in locale, cioè per fare il push, basta un comando:

git push origin nome-branch

Se non ci sono problemi, vedrai una schermata che conferma che tutto è sincronizzato:

Se il branch non esiste ancora su GitHub verrà creato in automatico, anche quando ti viene suggerito di fare una pull request.

Sul sito puoi verificare i branch contenuti in un repository cliccando su Branches.

Ti troverai così nella sezione dedicata.

Creare una pull request (PR)

Una pull request (PR) è un modo per segnalare ai proprietari di un repository le modifiche che vuoi apportare al loro codice, in modo che possano controllarle e decidere se applicarle al branch principale.

Per gli amministratori del repo la PR per il merge delle modifiche è facoltativa, ma utile a tenere traccia degli aggiornamenti; inoltre assicura che a essere modificato sia un ramo secondario (e non il main).

A volte è Git a suggerirti una PR – come dopo il push di un nuovo branch – e darti un link per farlo che ti basterà seguire, per poi fare clic sul pulsante Compare & pull request.

In tutti gli altri casi, puoi creare una PR da GitHub. Vai sul repository, nella sezione Pull requests, e clicca su New pull request.

Entrambe le strade portano alla pagina Compare changes, che mostra le modifiche per cui potresti fare una PR; per proseguire devi sceglierne una.

A questo punto vedrai ulteriori dettagli e potrai andare avanti con un clic su Create pull request.

Inserisci un titolo breve e una descrizione che spieghi cosa hai cambiato e perché (opzionale ma utile).

Puoi verificare che in Base ci sia il branch di destinazione delle modifiche – di solito il main – e in Compare il tuo nuovo branch. 

Se è tutto a posto leggerai Able to merge e potrai procedere con la richiesta cliccando sul pulsante verde.

Qui c’è anche la possibilità di assegnare il lavoro o richiedere revisioni ad altri membri della community, applicare etichette, definire il progetto d’appartenenza o delle milestone.

Per saperne di più sulle pull request puoi consultare la documentazione ufficiale di GitHub.

Fare il merge di una PR

In alcuni casi per fare il merge devi aspettare l’approvazione di un amministratore; se invece il repo è tuo ed è tutto a posto, puoi applicare subito le modifiche al branch principale col pulsante Merge pull request.

In questa pagina c’è anche uno spazio per i commenti che facilita l’interazione tra chi propone la PR e chi deve approvarla.

Dopo l’approvazione è meglio cliccare sul pulsante per cancellare il branch in modo da mantenere il repository in ordine.

Per verificare che i commit che avevi fatto a parte siano stati uniti al main, puoi vedere l’elenco nella prima pagina del repository.

Cliccando sul singolo commit si apre la pagina con i dettagli, compreso il codice hash che lo identifica. 

Si può usare il codice per annullare le modifiche col comando: 

git revert “codicehash” 

Riportare le modifiche da GitHub al pc

Quando facciamo le modifiche da GitHub abbiamo bisogno di riportarle anche in locale in modo da mantenere i repository allineati.

Vediamo come sincronizzare le modifiche da remoto a locale.

Per prima cosa, devi decidere quale branch vuoi sincronizzare. Se vuoi che il main locale recuperi gli aggiornamenti dal main remoto, devi associarli con:

git branch --set-upstream-to=origin/main main

Poi puoi preseguire con:

git pull

Se invece vuoi sincronizzare da un altro ramo remoto (es. nuovo-branch), puoi usare:

git pull origin nuovo-branch

Clonare un repository GitHub in locale

Per clonare un repository GitHub in locale bastano due passaggi.

Copia l’URL del repo (HTTPS o SSH), poi clona il repository in locale con il comando (sostituendo il tuo URL):

git clone https://github.com/nomeutente/nomerepo.git

Ora puoi lavorare sulla cartella dal tuo computer e poi eventualmente sincronizzare le modifiche in remoto come già visto.

Creare una issue

Vediamo come creare una issue su GitHub.

Accedi al repository in cui vuoi segnalare qualcosa e fai clic su Issues nella barra orizzontale in alto e poi sul pulsante New issue.

Inserisci un titolo che riassuma il problema o la proposta, ad esempio ‘Errore di visualizzazione nella homepage da mobile’.

Aggiungi una descrizione dettagliata del problema o della nuova funzionalità che vorresti. Ecco un esempio:
‘Quando si apre la homepage su dispositivi mobili, il pulsante Scopri di più non è visibile. Probabilmente c’è un errore nel CSS (…)’.

Anche qui hai opzioni come assegnare l’issue a un collaboratore, aggiungere etichette (labels), definire milestone e associare progetti.

Una volta creata, l’issue sarà visibile nel repository e chiunque abbia accesso potrà commentarla, proporre soluzioni o assegnarla.

Quando il problema è risolto, oppure se si decide di non occuparsene per altri motivi, l’issue va chiusa. 

Altre funzionalità di GitHub

Le funzionalità di GitHub sono davvero tante, come abbiamo intravisto nella panoramica iniziale. Qui scopriremo qualcosa in più su action, project e insights, che hanno ciascuna una pagina dedicata sul sito.

Actions

Come funzionano le action, cioè le automazioni di GitHub?

Le action si basano su un flusso di lavoro, definito tramite un file .yml che specifica:

• quando l’automazione deve partire (evento di attivazione)
• dove deve girare (es. ambiente Ubuntu, Windows)
• cosa deve fare (i vari job e step)

Vediamo le principali tipologie di GitHub Actions.

Le action di deployment servono per pubblicare in automatico un progetto ogni volta che viene aggiornato. Sono utili, ad esempio, quando si lavora su un sito o un’applicazione e si vuole che ogni nuova modifica venga distribuita su una piattaforma come Vercel, Netlify, Heroku, o su un server personale. 

Le action di integrazione si usano per collegare il repository a strumenti esterni che verificano l’affidabilità di ogni nuova modifica prima di unirla al progetto principale. Ad esempio, si possono automatizzare i test del software, eseguire controlli di stile o qualità del codice, oppure ricevere notifiche su Slack o via email quando qualcosa va storto. 

Le action di automazione sono pensate per gestire attività ripetitive e operative, come aggiornare le dipendenze, generare changelog, assegnare etichette alle issue o cancellare i file temporanei. Servono a semplificare le operazioni quotidiane, risparmiare tempo e ridurre gli errori.

Infine ci sono le action dedicate a GitHub Pages, che permettono di pubblicare e aggiornare un sito statico a partire dai contenuti di un repository. Ogni volta che i file – ad esempio pagine in HTML – vengono aggiornati, l’automazione si occupa di caricare il sito su GitHub Pages e renderlo visibile online.

Projects

I project su GitHub sono strumenti per pianificare e monitorare il lavoro all’interno di un repository o di un’organizzazione in modo visivo: delle bacheche simili a Trello o Kanban dove creare task, assegnarli, aggiungere scadenze e note.

I progetti aiutano a seguire l’avanzamento di un progetto, lavorare in team e avere sempre un quadro chiaro del lavoro da fare, in corso e completato. Inoltre sono personalizzabili con colonne, etichette e automazioni.

Puoi collegare un progetto a un repository creandolo al suo interno o, viceversa, aggiungendo uno o più repository a un progetto; associare alle varie fasi del lavoro rappresentate nel progetto issue, pull request e altre attività che riguardano il repo.

Andando su Projects > New project > Jump in right puoi aprire un nuovo progetto. O se preferisci puoi prima approfondire il funzionamento dei progetti leggendo la documentazione ufficiale.

Hai due opzioni: 

• partire da zero
• scegliere un template

Se parti da zero, hai a disposizione tre formati: table, board e roadmap.

Table mostra le attività dentro una tabella e consente di aggiungere molti dettagli in modo compatto e ordinato.

Board organizza i task in colonne drag-and-drop e aiuta a visualizzare lo stato di avanzamento del lavoro.

Roadmap mostra le attività su una linea temporale: utile per pianificare e comunicare le scadenze a lungo termine.

Se preferisci usare un template, ce ne sono tanti disponibili:

• Kanban – offre una panoramica visiva del flusso di lavoro, organizzando le attività in colonne come “Da fare”, “In corso” e “Completato”;
• Scrum – ideale per i team che usano il framework omonimo, permette di gestire backlog, pianificazioni e revisioni in modo strutturato;
• Bug Tracking – ideato per monitorare i bug: consente di registrarli, assegnarne la risoluzione e seguirne i progressi;
• Roadmap – aiuta a tracciare gli sviluppi futuri, fornendo una visione strategica dei prossimi passi del progetto;
• Release Planning – organizza tutte le attività legate a un rilascio software, dai test alla distribuzione finale;
• Team planning – facilita la definizione delle priorità e la distribuzione dei compiti all’interno del team;
• Feature release – supporta il coordinamento delle fasi necessarie per introdurre nuove funzionalità in produzione;
• Product launch – riunisce tutte le iniziative per il lancio di un prodotto, integrando design, sviluppo e marketing;
• Team retrospective – uno spazio dedicato alla riflessione collettiva su progetti conclusi, per capire cosa ha funzionato, cosa migliorare e come proseguire.

Insights

La sezione Insights di GitHub offre una panoramica sull’andamento di un repository: permette di monitorare l’evoluzione del progetto, identificare eventuali colli di bottiglia, valutare la partecipazione della community e analizzare i contributi degli utenti. 

La maggior parte di queste funzionalità sono disponibili solo per i repository pubblici e per gli account a pagamento.

All’interno di Insights trovi strumenti come Pulse, che mostra le attività recenti (commit, pull request, issue); Contributors, utile per vedere chi ha contribuito e quanto; Traffic, che fornisce dati su visualizzazioni e clonazioni del repository; Commits, che visualizza l’andamento temporale dei commit; Code frequency, che confronta righe aggiunte e rimosse nel tempo; e Dependency graph, per analizzare le librerie usate nel progetto.

Alternative a GitHub

GitHub non è l’unica piattaforma online capace di fare da ‘remote’ ai repository Git. 

Tra le alternative a GitHub più note ci sono GitLab e Bitbucket, Gogs e Gitea. 

GitLab è simile a GitHub per la gestione del codice, ma integra nativamente funzionalità DevOps come pipeline CI/CD, gestione ambienti e issue tracking. Esiste anche in versione self-hosted, ideale per team che vogliono controllo completo su sicurezza e personalizzazione.

Bitbucket è un prodotto Atlassian molto usato in ambienti aziendali perché è integrabile con strumenti come Jira e Trello. Supporta Bitbucket Pipelines per la CI/CD e, fino al 2020, anche il sistema Mercurial.

Soluzioni self-hosted come Gogs e Gitea, open source, sono comode per piccoli team o sviluppatori che preferiscono gestire Git nel modo più semplice e su server propri.

Conclusioni

In questa guida a GitHub abbiamo scoperto che è nato per facilitare il lavoro degli sviluppatori con Git, specialmente quello condiviso, e che oggi contiene strumenti di tutti i tipi per la gestione dei progetti, software ma non solo, e per la collaborazione efficace dei team.

Abbiamo sperimentato la creazione dei repository e dei branch e le principali funzionalità di GitHub: i commit, le pull request e i merge, i push e le issue.

Ora sappiamo che GitHub non offre solo il controllo di versione ma anche l’hosting di codice open source e siti statici, bacheche per pianificare e assegnare i task, funzionalità ‘social’ e altro ancora.

E tu hai già provato a usare GitHub per i tuoi progetti? Com’è andata? Raccontacelo nei commenti.