Git e GitHub: qual è la differenza e come sono collegati

Git e GitHub vengono confusi continuamente, anche se appartengono a livelli diversi. Git è il programma per il controllo di versione che installate sul computer: registra ogni stato salvato del progetto e permette di tornarvi. GitHub è un servizio web che ospita copie dei repository Git e attorno a cui sono costruiti gli strumenti per il lavoro di gruppo. Il modo più semplice per ricordarlo: Git è il motore, GitHub è l'officina in cui si può montare quel motore e lavorarci insieme agli altri.

Che cos'è Git

Git è un sistema di controllo di versione distribuito. Lo ha creato Linus Torvalds nel 2005 per lo sviluppo del kernel Linux, e da allora è diventato lo standard del settore. Git funziona interamente in locale: la cronologia delle modifiche è conservata nella cartella nascosta .git all'interno del progetto, e per la maggior parte delle operazioni non serve una connessione a Internet.

La parola «distribuito» è la chiave. Ogni partecipante al progetto ha sul proprio computer una copia completa del repository con tutta la cronologia, non soltanto gli ultimi file. Se il server dovesse sparire, il progetto si potrebbe ripristinare da qualsiasi macchina di lavoro.

Che cosa sa fare Git da solo:

• registrare le modifiche con i commit, cioè istantanee del progetto con autore, data e descrizione;
• mostrare chi, quando e perché ha cambiato una certa riga (git log, git blame);
• gestire linee di sviluppo parallele nei rami e unirle;
• annullare gli errori senza perdere il resto del lavoro;
• scambiare la cronologia con altri repository tramite git push, git pull e git fetch.

Git è un'utility da riga di comando. I client grafici e i pannelli integrati negli editor (VS Code, IntelliJ IDEA) sono soltanto interfacce sugli stessi comandi.

Che cos'è GitHub

GitHub è una piattaforma cloud per ospitare repository Git; oggi appartiene a Microsoft. Qui create un repository, inviate il vostro codice locale con git push e lo rendete disponibile ai colleghi, a un datore di lavoro o a tutta Internet, se il repository è pubblico.

Il valore di GitHub, però, non sta solo nell'archiviazione. Attorno al repository GitHub aggiunge ciò che in Git non c'è:

• Pull request — richiesta di fusione di un ramo con discussione e revisione del codice riga per riga;
• Issues — attività e segnalazioni di bug collegate al progetto;
• GitHub Actions — CI/CD: esecuzione automatica di test, build e deploy a ogni push;
• gestione degli accessi — chi può leggere, scrivere o unire nei rami protetti;
• profilo dello sviluppatore — grafico di attività e progetti pubblici che i recruiter consultano;
• GitHub Pages — hosting gratuito di siti statici direttamente dal repository.

Le ricerche come «git hub» o «github git» indicano di solito proprio questo servizio, raggiungibile su github.com. Il sito ufficiale di Git è invece git-scm.com, da cui si scarica il programma di installazione.

Git e GitHub a confronto

Come Git e GitHub lavorano insieme

Il collegamento tra i due è il remote, il repository remoto. Il repository locale conserva l'indirizzo del repository su GitHub con un nome breve, di default origin. Lo scambio avviene poi con tre comandi:

• git push — inviare al server i propri nuovi commit;
• git fetch — scaricare i commit altrui senza toccare i propri file;
• git pull — scaricare e subito integrare le modifiche nel ramo corrente (in sostanza fetch + merge o rebase).

Attenzione: GitHub non vede il vostro codice finché non lo inviate. Un commit esiste solo in locale fino al primo git push. Da qui nasce l'errore più frequente dei principianti: «ho fatto il commit, ma su GitHub non c'è nulla».

Il percorso tipico: dal progetto locale a GitHub

# 1. Creiamo il repository in locale
cd my-project
git init
git add .
git commit -m "Primo commit"

# 2. Creiamo un repository vuoto su github.com (senza README),
#    copiamo il suo indirizzo e lo colleghiamo come remote
git remote add origin git@github.com:username/my-project.git

# 3. Rinominiamo il ramo in main e inviamo
git branch -M main
git push -u origin main

Il flag -u (forma estesa --set-upstream) collega il ramo locale main a quello remoto. Da quel momento bastano git push e git pull senza argomenti.

Il percorso inverso: partire da un repository su GitHub

Se il progetto è già su GitHub, non lo si crea di nuovo: lo si clona.

git clone https://github.com/username/my-project.git
cd my-project

Il comando scarica tutta la cronologia e configura automaticamente il remote origin.

Autenticazione: SSH o HTTPS

Dal 2021 GitHub non accetta più la password dell'account per lavorare con Git tramite HTTPS. Le opzioni valide sono due.

HTTPS + Personal Access Token. Il token si crea nelle impostazioni dell'account (Settings → Developer settings) e si inserisce al posto della password. Per non doverlo digitare ogni volta, Git usa un gestore delle credenziali — su Windows è incluso in Git per Windows.

Chiavi SSH. È la soluzione che i datori di lavoro si aspettano sappiate configurare da soli:

# Generiamo la chiave
ssh-keygen -t ed25519 -C "you@example.com"

# Mostriamo la parte pubblica e la aggiungiamo su GitHub:
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# Verifichiamo la connessione
ssh -T git@github.com

In caso di successo GitHub risponde con un saluto con il vostro nome utente e la precisazione che non viene fornito accesso shell: è normale. In questo caso l'indirizzo del repository va usato nel formato git@github.com:user/repo.git, non https://.

Se il repository è già collegato tramite HTTPS, si può passare a SSH con un solo comando:

git remote set-url origin git@github.com:username/my-project.git

GitHub, GitLab e altri: qual è la differenza

GitHub non è l'unico hosting per Git. Tutti usano lo stesso Git, quindi un repository si può spostare da uno all'altro senza perdere la cronologia. La differenza sta nell'insieme di strumenti costruiti attorno al codice.

Su GitLab la richiesta di fusione si chiama merge request, su GitHub pull request, ma la sostanza è la stessa: proporre le modifiche di un ramo e discuterle prima di unirle. Cambia la terminologia, non i comandi Git.

In un unico repository locale si possono gestire più remote contemporaneamente, per esempio per tenere lo stesso progetto sia su GitHub sia su GitLab:

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

Serve GitHub se lavoro da solo?

Tecnicamente no: Git funziona benissimo in locale. Ma anche per un progetto personale il repository remoto offre tre vantaggi concreti.

• Copia di sicurezza. Se il portatile si rompe, il codice e tutta la cronologia sono al sicuro sul server.
• Lavoro da più dispositivi. A casa e in ufficio vi sincronizzate con push e pull.
• Portfolio. Per le selezioni per posizioni junior il profilo GitHub viene spesso guardato prima del curriculum: si cercano progetti veri, messaggi di commit sensati, un README.

Da dove partire se sei principiante

Non serve imparare Git e GitHub contemporaneamente: l'ordine conta. Prima padroneggiate il ciclo locale: git init, git status, git add, git commit, git log, i rami e la fusione. Quando lo usate senza guardare gli appunti, registratevi su GitHub, configurate SSH e imparate push, pull, fetch. L'ultimo passo è il processo di team: fork, ramo per ogni attività, pull request, revisione.

Che cosa guarda un datore di lavoro nel vostro GitHub

I quadratini verdi dell'attività non sono l'aspetto più importante. Un revisore esperto, in un paio di minuti, valuta altro:

• messaggi di commit chiari invece di «fix», «123», «modifiche»;
• commit piccoli e logici, non un unico enorme «caricato tutto il progetto»;
• un README che spiega come avviare il progetto;
• un file .gitignore: nel repository non ci sono node_modules, file .env con password o file dell'IDE;
• rami e pull request anche nei progetti didattici: dimostrano che conoscete il processo di lavoro in team.

Errori tipici dei principianti

«fatal: not a git repository»

State eseguendo un comando Git fuori da un repository. Spostatevi nella cartella del progetto oppure eseguite git init. La registrazione su GitHub non c'entra: è un errore locale di Git.

«Permission denied (publickey)»

La chiave SSH non è stata creata, non è stata aggiunta a GitHub oppure non è stata caricata nel ssh-agent. Controllate con ssh -T git@github.com e l'elenco delle chiavi nelle impostazioni dell'account.

«rejected … (fetch first)» durante il push

Sul server ci sono commit che voi non avete — per esempio perché avete creato il repository su GitHub con un README. Prima recuperate le modifiche: git pull --rebase origin main, poi ripetete git push. Non usate --force finché non sapete il lavoro di chi state per sovrascrivere.

Segreti in un repository pubblico

Una password o una chiave API finita una volta in un commit resta nella cronologia, anche se il file viene cancellato in seguito. Una chiave del genere va revocata subito, mentre .env va inserito in .gitignore fin dall'inizio.

Riepilogo

Git è lo strumento di controllo di versione sul vostro computer; GitHub è il servizio in cui questi repository vivono nel cloud e in cui si costruisce il lavoro di team. GitLab, Bitbucket e gli altri sono alternative a GitHub, non a Git: sotto il cofano usano tutti gli stessi commit, rami e comandi. Iniziate con Git in locale, poi collegate un remote e configurate SSH. Il collegamento tra repository locale e GitHub, push, pull e fetch li analizziamo in pratica nel corso di Git.