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

Una distinzione utile è questa:

Git

Lavora sul tuo computer. Tiene traccia dei cambiamenti. Crea commit. Gestisce branch.

GitHub

Lavora online. Ospita repository remoti. Mostra file, commit, branch e cronologia. Permette condivisione e collaborazione.

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.

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

Solo tu e le persone invitate potete vederlo. È 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.

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

Push: mandare online i cambiamenti

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

Detto in modo semplice:

• 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 la fotografia nella cronologia locale. Il push manda quella fotografia 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 scarichi in locale i cambiamenti presenti nel repository remoto.

È utile quando:

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

Comando base:

git pull

Anche qui, più del comando, conta il concetto: sincronizzare il locale con il remoto.

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

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ì:

• 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

All’inizio puoi anche lavorare quasi sempre su main, soprattutto se sei da solo e il progetto è piccolo.

Però capire che i branch esistono è importante.

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: una fotografia dei file in un momento preciso.

Quando fai push, quei commit arrivano su GitHub e diventano visibili 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.

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

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

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.

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.
• Workflow base semplice e sano: pull, lavoro locale, status, add, commit chiaro, push, verifica su GitHub.
• 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.