Questa guida nasce con un obiettivo molto semplice: aiutare chi parte da zero a capire GitHub in modo chiaro, senza perdersi tra termini tecnici e spiegazioni confuse.

Non è un manuale completo su tutto ciò che GitHub può fare, e non pretende di esserlo.

È una guida pratica, pensata per chi vuole capire le basi davvero utili, iniziare a usare GitHub con un minimo di sicurezza e costruire un piccolo workflow semplice ma sensato.

Se in futuro vorrai approfondire argomenti più avanzati, potrai farlo consultando la documentazione ufficiale, corsi completi e strumenti più tecnici. Ma per iniziare bene, nella maggior parte dei casi, non serve sapere tutto. Serve capire le cose giuste.

GitHub è una piattaforma online che lavora insieme a Git.

La prima distinzione da fissare è questa: Git e GitHub non sono la stessa cosa.

Se prima vuoi consolidare bene le basi di Git lato locale, puoi passare anche dalla guida Git pratico senza panico.

Git è lo strumento di versionamento che lavora sui file del tuo progetto. GitHub invece è un servizio online che ti permette di pubblicare, salvare, condividere e gestire quei progetti in rete.

In sintesi:

• Git è lo strumento.
• GitHub è il posto online dove puoi mettere i progetti Git.

In pratica: Git gestisce la cronologia del progetto, GitHub lo ospita online e facilita la collaborazione.

GitHub viene usato per molti motivi:

• tenere una copia online dei progetti
• mostrare il proprio lavoro
• collaborare con altre persone
• organizzare codice, documentazione e file
• creare una sorta di portfolio tecnico

GitHub è utile anche da solo, senza team e senza progetti enormi. Anche un progetto semplice può trarre vantaggio da GitHub.

Molti all’inizio dicono “sto usando GitHub” quando in realtà stanno usando Git nel terminale. Oppure pensano che GitHub sia obbligatorio per usare Git. Non è così.

Puoi usare Git anche senza GitHub. Puoi avere un progetto locale sul tuo computer, usare commit, vedere la cronologia e lavorare tranquillamente senza mai pubblicarlo online.

GitHub entra in gioco quando vuoi:

• avere un backup online
• sincronizzare il progetto tra più computer
• condividere il repository
• pubblicare il lavoro
• collaborare

Il modo piu semplice per non confonderti è questo: Git lavora prima di tutto sul tuo computer. GitHub lavora prima di tutto online.

Git

Lavora sul tuo computer. Qui modifichi i file, fai commit, cambi branch e controlli la cronologia locale.

GitHub

Lavora online. Qui pubblichi il repository remoto, vedi branch e commit su web, apri Pull Request, leggi issue e collabori.

Detto ancora piu terra-terra:

• se stai modificando file, facendo commit o usando git status, stai lavorando con Git;
• se stai guardando il repository nel browser, aprendo una PR o gestendo issue, stai lavorando con GitHub.

GitHub non è solo “hosting del codice”: aggiunge anche strumenti operativi che userai nel lavoro quotidiano, tra cui:

• Issues
• Pull Request
• Actions
• Wiki
• Projects

Capire questa differenza all’inizio ti evita molti fraintendimenti nei passaggi successivi.

Uno degli errori più comuni è pensare che GitHub serva solo ai team o agli sviluppatori già esperti.

In realtà GitHub è utilissimo anche se lavori da solo, soprattutto se stai imparando.

Perché?

3.1 Ti dà una copia online del progetto

Se il computer ha problemi, avere il repository online può salvarti il lavoro.

Non è una magia automatica: funziona bene se fai push con regolarità e non lasci tutto solo in locale per giorni.

3.2 Ti aiuta a presentarti meglio

Se un giorno vuoi mostrare i tuoi progetti, GitHub è uno dei primi posti dove molte persone guardano.

3.3 Ti abitua a un workflow reale

Anche se fai piccoli progetti personali, usare GitHub ti avvicina a un metodo di lavoro molto comune.

3.4 Ti costringe a essere un po’ più ordinato

README, nomi dei repository, commit, struttura dei file: tutte cose che ti spingono a lavorare con più criterio.

Aprire un account GitHub è semplice, ma ci sono alcune piccole scelte che conviene fare con attenzione.

Quando crei l’account, cerca di scegliere:

• un nome utente pulito e credibile
• un’email che userai davvero
• una password sicura

Se l’account sarà anche parte della tua presenza online, il nome utente conta. Non serve essere super istituzionali, ma evitare nomi troppo casuali può aiutare.

Dopo la registrazione puoi completare alcune informazioni:

• foto profilo
• bio breve
• link sito personale
• località

Non è obbligatorio riempire tutto subito, ma un profilo minimo ordinato fa già una buona impressione.

Consiglio operativo: attiva subito la verifica a due fattori (2FA). È una delle impostazioni più importanti per proteggere l’account.

Su GitHub il contenitore principale di un progetto si chiama repository, spesso abbreviato in repo.

Un repository contiene:

• file del progetto
• cartelle
• cronologia dei commit
• eventuali branch
• informazioni sul progetto
• README e altri documenti

Puoi pensarlo come la casa del tuo progetto.

Se hai un piccolo progetto, un esercizio, una guida o un’applicazione semplice, ogni progetto può avere il suo repository.

Quando crei un repository devi scegliere anche la visibilità: pubblico o privato.

Repository pubblico

Chiunque può vedere il contenuto. È utile per:

• portfolio
• progetti dimostrativi
• codice che vuoi condividere
• esercizi che vuoi rendere visibili

Repository privato

In generale è visibile solo a te e alle persone che hanno accesso. Nei repository di organizzazione i permessi possono dipendere anche da team, ruoli e impostazioni interne.

È utile per:

• progetti in lavorazione
• esperimenti ancora disordinati
• materiale non pronto
• contenuti che non vuoi rendere pubblici

Essere pubblici non è obbligatorio. All’inizio è meglio un progetto privato ma ordinato, piuttosto che un progetto pubblico poco curato.

Consiglio operativo: assegna a ogni repository uno scopo preciso. Evita contenitori generici con progetti diversi mescolati: rendono più difficile orientarsi, collaborare e mantenere il lavoro nel tempo.

Nota di sicurezza: non caricare mai segreti nel repository (token, password, file .env). Anche in repo privato è una buona abitudine trattarli come dati sensibili.

Quando apri un repository su GitHub, trovi diverse aree importanti.

Nome del repository

È il nome del progetto. Cerca di mantenerlo chiaro.

Tab dei file

Qui vedi cartelle e file presenti nel progetto.

README

Se presente, appare spesso in basso nella home del repository ed è una delle prime cose che si leggono.

Commit recenti

Ti mostrano gli ultimi cambiamenti registrati.

Branch

Ti fanno vedere se stai guardando il ramo principale o un altro ramo del progetto.

Insights, settings e altre sezioni

Sono sezioni utili, ma all’inizio conviene concentrarsi prima sulle basi.

Consiglio operativo: quando apri un repository, controlla subito branch selezionato e ultimo commit visibile in alto: ti evita modifiche sul ramo sbagliato.

Puoi creare un repository direttamente dal sito di GitHub.

I passaggi tipici sono questi:

1. clic su “New repository”
2. scegli un nome
3. aggiungi una descrizione facoltativa
4. scegli se pubblico o privato
5. decidi se inizializzarlo con README

Per chi inizia, il nome del repository conta molto perché aiuta a mantenere ordine nel tempo.

• se hai un solo progetto, un nome semplice e chiaro è sufficiente
• se prevedi più progetti, conviene usare una convenzione coerente fin da subito

Esempi semplici di convenzione:

• landing-page-studio, portfolio-frontend, api-prenotazioni
• 00-setup-ambiente, 01-sito-vetrina, 02-dashboard-admin

La numerazione non è obbligatoria, ma può aiutare se stai costruendo un percorso progressivo o una serie di progetti collegati.

La regola pratica è: scegli una struttura e mantienila costante su tutti i repository.

• nomi brevi, leggibili e senza ambiguità
• niente spazi, meglio trattini (-)
• descrizione repository compilata con una frase utile
• README iniziale quasi sempre attivo

Se stai partendo da zero e vuoi un progetto semplice, inizializzarlo con README è spesso la scelta migliore.

Se invece hai già il progetto sul tuo computer e vuoi collegarlo dopo, puoi creare il repository vuoto e aggiungere i file dal locale.

Per collegare un progetto locale a GitHub, prendiamo in esame i due casi più utili.

Caso A: usi solo Git. In questo caso il repository su GitHub deve essere già stato creato.

git init
git add .
git commit -m "Primo commit"
git branch -M main
git remote add origin https://github.com/USERNAME/NOME-REPO.git
git push -u origin main

Caso B: fai tutto da terminale. Se non vuoi aprire il sito GitHub, devi usare GitHub CLI (gh) per creare il repository remoto.

gh auth login
gh repo create NOME-REPO --private --source=. --remote=origin --push

Se vuoi un repository pubblico, usa --public al posto di --private.

Questo comando presuppone che la cartella corrente sia già un repository Git locale o che tu voglia inizializzarlo nel flusso guidato della CLI. Se non hai ancora preparato il progetto in locale, conviene prima sistemare repository, commit iniziale e file da pubblicare.

Consiglio operativo: pensa così: git gestisce il progetto locale, gh crea il repository su GitHub da terminale.

La sequenza mentale giusta è questa:

• prima esiste il progetto locale;
• poi lo colleghi a un repository remoto su GitHub;
• poi fai push per mandare online i commit.

Push: mandare online i cambiamenti

La parola push significa inviare i commit locali al repository remoto.

Detto nel modo piu semplice possibile: hai gia salvato il lavoro in locale con un commit, e con push lo mandi anche su GitHub.

• fai modifiche sul computer
• le salvi con un commit
• fai push
• i cambiamenti arrivano su GitHub

Molti principianti credono che salvare un file o fare commit significhi già aver aggiornato GitHub. Non è così.

Il commit salva il lavoro nella cronologia locale. Il push manda quei commit anche online.

Esempio tipico:

git add .
git commit -m "Aggiorna sezione contatti"
git push

Consiglio operativo: prima di fare push usa sempre git status. Ti aiuta a evitare file involontari nei commit.

Pull: portare in locale i cambiamenti online

Il comando complementare a push è pull.

Con pull porti sul tuo computer i cambiamenti che nel frattempo sono arrivati su GitHub.

È utile quando:

• lavori da due computer diversi
• collabori con qualcuno
• hai fatto modifiche online e vuoi ritrovarle sul computer

Comando base:

git pull

Qui c'è il punto che spesso frega chi inizia: pull non vuol dire solo “scarica”.

pull scarica e prova anche a integrare quei cambiamenti nel branch su cui sei adesso.

Nella configurazione più comune equivale a fetch + merge. In alcuni workflow può usare rebase. Per questo non va trattato come un pulsante innocuo da premere a caso.

Consiglio operativo: se lavori da solo e vuoi una cronologia più lineare, valuta git pull --rebase invece di git pull.

Riassunto secco:

• push = dal tuo computer a GitHub;
• pull = da GitHub al tuo computer.

La Pull Request, spesso abbreviata in PR, è uno dei punti centrali di GitHub.

In parole semplici, una PR è una richiesta per dire: ho finito questa modifica in un branch, adesso voglio confrontarla con un altro branch e decidere se unirla.

Non è utile solo nei grandi team. Serve anche da solo, perché ti costringe a separare meglio il lavoro, rileggere il diff e fare un minimo di controllo qualità prima di unire tutto nel branch principale.

Il flusso base più comune

1. crei un branch per una modifica specifica
2. fai commit locali
3. pushi il branch su GitHub
4. apri una Pull Request
5. rivedi differenze, commenti e stato dei controlli
6. fai merge quando è tutto a posto

Esempio semplice

git switch -c feature/faq-home
git add .
git commit -m "aggiunge sezione FAQ in home"
git push -u origin feature/faq-home

A quel punto su GitHub puoi aprire una PR da feature/faq-home verso main.

La cosa pratica da capire è questa: la PR non modifica da sola il codice del branch principale. La PR apre un confronto e una proposta di merge.

Cosa guardare dentro una PR

• titolo chiaro
• descrizione sintetica di cosa cambia
• diff dei file modificati
• eventuali commenti o review
• stato dei controlli automatici, se presenti

La PR non è solo un pulsante per fare merge. È un momento di controllo: guardi se le modifiche hanno senso, se il branch è quello giusto e se stai unendo davvero quello che volevi unire.

Una distinzione utile

Branch e Pull Request non sono la stessa cosa.

• il branch è la linea di lavoro separata
• la Pull Request è la proposta di unire quella linea in un altro branch

Detto ancora piu secco:

• il branch è dove lavori;
• la PR è dove controlli e proponi l'unione.

Consiglio operativo: anche se lavori da solo, aprire una PR per modifiche medio-grandi ti aiuta a ragionare meglio prima del merge.

Il file README.md è uno degli elementi più importanti di un repository.

Molti lo ignorano all’inizio, ma è un errore. Un buon README rende il progetto più chiaro, più presentabile e più utile anche a te stesso.

Dentro un README puoi scrivere:

• cos’è il progetto
• a cosa serve
• tecnologie usate
• come avviarlo
• struttura base
• eventuali note importanti

Per un progetto piccolo non serve un README lungo: bastano informazioni chiare e utili.

Un esempio minimale potrebbe contenere:

• titolo del progetto
• breve descrizione
• stack usato
• istruzioni rapide
• stato del progetto

Il README si scrive quasi sempre in Markdown, un formato semplice che ti permette di creare titoli, elenchi, link e blocchi di codice.

# Titolo principale
## Sottotitolo
**testo in grassetto**
- elemento lista
- altro elemento

Markdown resta leggibile anche mentre scrivi e non richiede sintassi complicata.

Consiglio operativo: aggiungi sempre una sezione “Avvio rapido” con 2-3 comandi. È la parte che chi legge cerca per prima.

Un branch è un ramo del progetto.

Il branch principale oggi si chiama spesso main.

Per capire il concetto senza tecnicismi, pensa così: un branch è una linea di lavoro separata.

• il branch principale è la versione principale del progetto
• un branch secondario è uno spazio dove puoi fare prove o sviluppare una modifica senza toccare subito la versione principale

Su micro-progetti personali può capitare di lavorare direttamente su main, soprattutto all’inizio.

Però appena il lavoro cresce un po’, o vuoi fare modifiche più rischiose, conviene passare a branch dedicati.

Il vantaggio pratico è questo: puoi lavorare a una modifica senza sporcare subito main.

Sono utili, ad esempio, quando vuoi:

• rifare una sezione del sito
• testare una nuova feature
• provare un refactor
• tenere separata una demo dalla versione base

Non serve creare branch per cambiare una virgola. Ma in certi casi aiutano parecchio.

Esempi pratici:

• vuoi rifare tutta la navbar
• stai lavorando a una nuova pagina
• vuoi preparare una versione demo
• vuoi fare modifiche grosse senza sporcare subito il main

L’idea non è complicarti la vita, ma proteggere il progetto principale mentre lavori.

Consiglio operativo: usa nomi branch descrittivi, ad esempio feature/navbar-mobile, fix/form-validation, docs/readme-update.

Un commit è un salvataggio tracciato del progetto nella cronologia Git.

Finché resta solo in locale, lo vedi sul tuo computer. Quando fai push, quel commit arriva anche su GitHub e diventa visibile nella cronologia del repository.

La cronologia serve perché ti fa capire con chiarezza:

• cosa è cambiato
• quando è cambiato
• con quale messaggio
• chi ha fatto la modifica

Anche se lavori da solo è fondamentale: dopo qualche giorno potresti non ricordare più cosa hai toccato e perché.

Flusso base:

git add .
git commit -m "aggiorna sezione contatti"
git push

La parte più importante è il messaggio del commit: deve spiegare in una riga cosa hai cambiato.

Regola semplice: verbo + oggetto della modifica.

Messaggi vaghi da evitare:

• update
• fix
• prova
• wip

Messaggi chiari:

• aggiunge sezione FAQ
• aggiorna layout pagina contatti
• rimuove componenti non più usati
• migliora struttura del footer

Se in un commit metti modifiche diverse (esempio: navbar + form + README), la cronologia diventa difficile da leggere.

Consiglio operativo: fai commit piccoli e coerenti: una modifica chiara per ogni commit.

GitHub permette anche di modificare piccoli file direttamente dal browser.

Questa funzione può essere utile per:

• correggere un README
• aggiungere una nota
• sistemare piccoli dettagli testuali

Puoi anche caricare file direttamente da GitHub tramite interfaccia web.

Ci sono però due limiti pratici da sapere subito:

• se il branch è protetto, GitHub può impedirti di modificare o caricare file direttamente lì dal browser;
• l’upload via web non è pensato per file grandi o per flussi strutturati di sviluppo.

Modificare e caricare dal browser è utile per interventi rapidi, ma non dovrebbe diventare il flusso principale.

Per un workflow ordinato è meglio:

• lavorare in locale
• usare Git
• fare commit
• fare push

Per modifiche grandi o strutturali è meglio lavorare in locale: dal browser diventa presto scomodo e confuso.

Consiglio operativo: usa il browser per micro-fix veloci, non per sviluppo completo.

Clone e fork sembrano simili, ma servono a cose diverse.

Clone

Il comando clone serve a scaricare un repository esistente sul tuo computer.

Esempio:

git clone URL_DEL_REPOSITORY

È utile quando:

• vuoi lavorare a un repository già presente su GitHub
• stai passando su un altro computer
• vuoi scaricare un tuo progetto online

Clone crea una copia locale completa del repository.

Fork

Il fork è una copia di un repository dentro il tuo account GitHub.

In breve:

• clone = copia sul tuo computer
• fork = copia nel tuo account GitHub

Questa è la differenza che conta davvero: il clone lavora sul piano locale, il fork lavora sul piano online.

Il fork è utile soprattutto quando vuoi partire da un progetto pubblico esistente o contribuire a un repository che non controlli direttamente.

In molti casi il fork è associato al flusso “fork -> clone -> branch -> commit -> push -> pull request” usato quando non hai permessi diretti di scrittura sul repository originale.

Consiglio operativo: se il repository è tuo, nella maggior parte dei casi ti basta fare clone. Usa fork quando lavori su repository di altri.

In questo punto vediamo meglio cosa sono le funzioni extra principali di GitHub, una per una.

Issues

Una issue è una scheda di lavoro: serve a descrivere una cosa da fare, un problema da risolvere o un miglioramento.

In pratica ti aiuta a non perdere pezzi e a capire cosa manca nel progetto.

Pull Request

È una richiesta di integrazione: proponi modifiche fatte in un branch e chiedi di unirle nel branch principale.

Serve per review, confronto e controllo qualità prima del merge.

Actions

Sono automazioni eseguite da GitHub: test automatici, build, deploy e controlli sul codice.

Detto semplice: sono lavori che GitHub esegue da solo quando succede qualcosa, per esempio un push o una Pull Request.

Ti aiutano a ridurre errori manuali e a standardizzare il flusso.

Wiki

È uno spazio di documentazione interna del repository.

Utile per guide, procedure e note tecniche più lunghe del README.

Projects

È una bacheca organizzativa (stile Kanban) per pianificare e tracciare attività.

Ti aiuta a vedere cosa è da fare, cosa è in corso e cosa è completato.

• Errori comuni da evitare: non confondere Git con GitHub, non lavorare solo da browser, non fare commit vaghi, non trattare pull e PR come passaggi automatici da fare senza controllo.
• Workflow base semplice e sano: aggiorni il contesto, lavori in locale o in branch, fai commit chiari, pushi, controlli su GitHub e usi PR quando serve.
• Un esempio pratico completo: modifica file, git add, git commit, git push, controllo finale online.
• Cosa non serve sapere subito: automazioni avanzate, permessi complessi e strategie sofisticate possono aspettare.
• GitHub e crescita personale nel proprio percorso: ti aiuta a lavorare con più ordine, tracciabilità e continuità.

Se applichi questi punti con costanza, GitHub diventa uno strumento operativo chiaro e affidabile.

Guide correlate

• Git pratico senza panico: basi operative locali, commit, branch, merge e recupero errori.
• Tutti i tutorial: elenco aggiornato delle guide disponibili.