Git 01
🔀 Git & GitHub · Modulo 1 · Lezione 01
Cos’è il controllo di versione 📜
Perché serve · Come funziona concettualmente · Breve storia di Git · Versioning manuale vs automatico
💡 Hai mai rinominato un file relazione_v2_FINALE_definitiva_VERA.docx? Allora hai già fatto controllo di versione — nel modo peggiore possibile. Questa lezione ti mostra perché esiste un modo migliore, come funziona concettualmente, e perché Git è diventato lo standard usato da milioni di sviluppatori, aziende e — sempre più — scuole.
🎯 Obiettivi della lezione
- Capire cos’è il controllo di versione e quale problema risolve
- Confrontare il versioning manuale (copie, nomi file) con quello automatico (VCS)
- Conoscere la differenza tra sistemi centralizzati e distribuiti
- Capire perché Git ha vinto la “battaglia” dei VCS
- Conoscere la differenza tra Git e GitHub
- Avere un vocabolario minimo: repository, commit, branch, merge
📖 1. Teoria
1.1 — Il problema: tenere traccia delle modifiche
Immagina di scrivere una tesina con un compagno. Lavorate sullo stesso file Word. Ecco cosa succede senza un sistema di versioning:
├── tesina.docx
├── tesina_v2.docx
├── tesina_v2_marco.docx
├── tesina_v2_marco_corretta.docx
├── tesina_FINALE.docx
├── tesina_FINALE_v2.docx
├── tesina_FINALE_VERA.docx
├── tesina_FINALE_VERA_consegna.docx
└── tesina_FINALE_VERA_consegna_CORRETTA.docx
Questo è il versioning manuale: copie di file con nomi diversi. Funziona (male) per un singolo documento, diventa un disastro con un progetto di programmazione che ha decine o centinaia di file, e collassa completamente quando più persone lavorano in parallelo.
I problemi del versioning manuale sono concreti e familiari a chiunque abbia lavorato in gruppo:
Nessuna storia: impossibile sapere cosa è cambiato tra una versione e l’altra, chi l’ha cambiato e perché.
Nessun rollback: hai cancellato un paragrafo tre giorni fa e ora lo rivuoi? Se non hai salvato una copia, è perso per sempre.
Caos nei nomi: quale file è quello “vero”?
_FINALE o _FINALE_v2?
Storia completa: ogni modifica è registrata con data, autore e messaggio — puoi risalire a qualsiasi stato passato del progetto.
Rollback istantaneo: vuoi tornare alla versione di tre giorni fa? Un comando e ci sei.
Un solo file, molte versioni: non serve rinominare nulla. Il file si chiama sempre
tesina.docx — la storia è gestita dal sistema.
1.2 — Cos’è un sistema di controllo di versione (VCS)
Un Version Control System (VCS) è un software che registra le modifiche apportate a un insieme di file nel tempo, in modo che tu possa richiamare qualsiasi versione precedente in qualsiasi momento. Pensa a un VCS come a un “salva partita” infinito: ogni volta che salvi, il sistema memorizza una fotografia completa del tuo progetto in quel momento. Puoi saltare avanti e indietro tra queste fotografie quando vuoi.
I concetti fondamentali di qualsiasi VCS sono quattro:
📌 Analogia del videogioco: un repository è la tua partita. Un commit è un salvataggio. Un branch è quando dici “provo a esplorare questa grotta — se muoio, ricarico il salvataggio precedente”. Un merge è quando decidi che l’esplorazione è andata bene e la incorpori nella tua partita principale.
1.3 — Centralizzato vs distribuito
Non tutti i VCS funzionano allo stesso modo. La distinzione più importante è tra sistemi centralizzati e distribuiti.
↕️ ↕️ ↕️
💻 💻 💻
Solo file Solo file Solo file
↕️ ↕️ ↕️
💻 💻 💻
Repo completo Repo completo Repo completo
1.4 — Breve storia di Git
Git è nato nel 2005 da una necessità concreta: il kernel Linux — il progetto open source più grande del mondo, con migliaia di sviluppatori — aveva bisogno di un nuovo sistema di controllo versione. Il creatore di Linux, Linus Torvalds, decise di costruirne uno da zero.
📌 Curiosità sul nome: Linus Torvalds, con il suo tipico umorismo, ha dichiarato che “git” è slang britannico per “persona stupida” e che nomina tutti i suoi progetti come se stesso — prima Linux, poi Git.
1.5 — Git ≠ GitHub
Questa è la confusione più comune tra chi inizia. Chiariamola subito con un confronto diretto:
| Git | GitHub | |
|---|---|---|
| Cos’è | Un software | Un servizio web |
| Dove gira | Sul tuo computer | Su internet (github.com) |
| Creato da | Linus Torvalds (2005) | Tom Preston-Werner, Chris Wanstrath, PJ Hyett (2008) |
| Serve Internet? | No — funziona offline | Sì — è un sito web |
| Cosa fa | Traccia le modifiche ai file | Ospita repository Git + aggiunge collaborazione (issue, PR, Actions) |
| Ha alternative? | Mercurial, SVN (ma Git domina) | GitLab, Bitbucket, Codeberg |
| Costo | Gratuito e open source | Gratuito (piano base) o a pagamento (team/enterprise) |
Git
Versioning locale
⬆️ push ⬇️ pull
🌐
GitHub
Hosting + collaborazione
1.6 — Come funziona Git: il modello a snapshot
La maggior parte dei VCS tradizionali (SVN, CVS) memorizzano le differenze tra una versione e l’altra — “nella riga 42 del file X, sostituisci ‘ciao’ con ‘hello'”. Git funziona diversamente: ad ogni commit, Git memorizza una fotografia completa (snapshot) di tutti i file del progetto. Se un file non è cambiato, Git non lo duplica — salva solo un puntatore alla versione precedente.
v2: Δ_A — Δ_C
v3: — Δ_B Δ_C
Per ricostruire v3 devo applicare tutti i delta in sequenza: lento
v2: file_A₂ file_B₁ file_C₂
v3: file_A₂ file_B₂ file_C₃
Per ricostruire v3 prendo direttamente lo snapshot: istantaneo
Questo modello ha conseguenze pratiche importanti: passare da un branch all’altro è istantaneo (basta cambiare quale snapshot è “attivo”), e la maggior parte delle operazioni — log, diff, blame — avvengono localmente, senza toccare il server. Ecco perché Git è così veloce.
1.7 — I tre stati di Git
Git gestisce i tuoi file attraverso tre aree. Questo è il concetto più importante da capire prima di toccare il terminale — lo approfondirai nella Lezione 04, ma ecco un’anteprima:
Modifichi, crei, cancelli qui.
per il prossimo commit.
git addLo snapshot è salvato per sempre.
git commitL’idea della staging area è peculiare di Git e all’inizio sembra inutilmente complicata. Ma ha un vantaggio potente: puoi scegliere quali modifiche includere in un commit, anche se hai cambiato molti file. Questo ti permette di fare commit piccoli, mirati e ben descritti — una pratica fondamentale per lavorare bene in team.
📌 Analogia del carrello: stai facendo la spesa (working directory). Metti i prodotti che vuoi comprare nel carrello (staging area con git add). Alla cassa paghi e quei prodotti diventano tuoi (repository con git commit). Puoi anche togliere qualcosa dal carrello prima di pagare — non sei obbligato a comprare tutto quello che hai toccato.
1.8 — Perché Git ha vinto
Ci sono state decine di VCS nella storia dell’informatica. Perché Git ha finito per dominare il 95%+ del mercato? Cinque ragioni concrete:
| Fattore | Perché conta |
|---|---|
| ⚡ Velocità | Quasi tutte le operazioni sono locali. Creare un branch: millisecondi. Fare un commit: millisecondi. In SVN queste operazioni richiedevano secondi o minuti perché serviva il server. |
| 🌿 Branch leggeri | In Git un branch è solo un puntatore (41 byte). In SVN era una copia fisica dell’intera cartella. Questo ha reso i branch una pratica quotidiana invece che un evento raro. |
| 🔒 Integrità | Ogni file, ogni commit, ogni struttura è verificata con un hash SHA. È impossibile modificare la storia senza che Git se ne accorga. Nessun file corrotto passa inosservato. |
| 🌐 Distribuito | Ogni copia è un backup completo. Lavori offline. Nessun singolo punto di guasto. |
| 🐙 GitHub | GitHub ha reso Git accessibile anche ai non-esperti e ha creato un ecosistema di collaborazione open source che ha attratto milioni di sviluppatori. |
💻 2. Esempi guidati
Questa lezione è teorica — non eseguirai comandi (quello inizia dalla Lezione 02). Ma ecco un’anteprima visiva di cosa farai nelle prossime lezioni, per darti un’idea concreta di come si lavora con Git.
Anteprima A — Il tuo primo repository e commit
$ cd mio-progetto # entra nella cartella
$ git init # trasforma la cartella in un repository Git
Initialized empty Git repository in /home/studente/mio-progetto/.git/
$ echo “Ciao mondo” > readme.txt # crea un file
$ git add readme.txt # metti il file nella staging area
$ git commit -m “Primo commit: aggiunto readme” # salva lo snapshot
[main (root-commit) a3b8f2c] Primo commit: aggiunto readme
1 file changed, 1 insertion(+)
Anteprima B — Vedere la storia
c4d9e1a Aggiunto stile al paragrafo introduttivo
8b2f3c7 Corretta lista delle fonti
a3b8f2c Primo commit: aggiunto readme
Anteprima C — Branch e merge
Switched to a new branch ‘nuova-funzione’
# … lavori, fai commit sul branch …
$ git switch main # torni al branch principale
$ git merge nuova-funzione # integri il lavoro
Merge made by the ‘ort’ strategy.
🏋️ 3. Esercizi
Essendo la prima lezione, gli esercizi sono di riflessione e comprensione — non ci sono comandi da eseguire.
🟢 Esercizio 1 — Analizza il tuo workflow attuale (Facile)
Pensa all’ultimo progetto di gruppo su cui hai lavorato (tesina, presentazione, progetto di programmazione). Rispondi a queste domande:
- Come vi scambiavate i file? (email, WhatsApp, chiavetta USB, Google Drive…)
- È mai successo che qualcuno sovrascrivesse il lavoro di un altro?
- Se dovevi tornare a una versione precedente, come facevi?
- Quante copie del file “finale” esistevano alla fine del progetto?
- Quale dei problemi del paragrafo 1.1 hai sperimentato di persona?
🔵 Esercizio 2 — Mappa i concetti (Medio)
Associa ciascuna situazione quotidiana al concetto Git corrispondente. Per ciascuna, scrivi il termine (repository, commit, branch, merge):
b) La cartella con tutti i file del progetto e tutta la cronologia → ???
c) Decidi di provare una struttura diversa per il capitolo 3, senza toccare la versione attuale → ???
d) La nuova struttura funziona — la incorpori nella versione principale → ???
e) Marco lavora sulla bibliografia mentre Giulia lavora sull’introduzione, ciascuno nella propria versione → ???
f) Marco e Giulia uniscono le loro modifiche in un’unica versione → ???
🟠 Esercizio 3 — Centralizzato vs Distribuito (Medio)
Per ciascuno di questi scenari, indica se un VCS centralizzato o distribuito sarebbe più adatto, e perché:
b) Un’azienda vuole che il codice sorgente sia su un unico server controllato, e gli sviluppatori non possano avere copie complete sul loro laptop.
c) Un progetto open source con 500 contributori sparsi in tutto il mondo.
d) Il disco del server si rompe. Con quale sistema il danno è minore?
🟣 Esercizio 4 — Snapshot vs Delta (Difficile)
Un progetto ha 3 file (A, B, C). In 4 commit, le modifiche sono:
Commit 2: modificato solo A
Commit 3: modificati B e C
Commit 4: modificato solo C
Domande:
a) In un sistema a delta, quanti delta vengono memorizzati in totale nei 4 commit?
b) In un sistema a snapshot (Git), quanti snapshot di file vengono memorizzati? Quanti sono puntatori a versioni precedenti (cioè file non modificati)?
c) Se devi ricostruire lo stato del progetto al Commit 3, quale sistema è più veloce e perché?
❓ 4. Quiz di verifica
1. Qual è il problema principale del versioning manuale (copie di file rinominati)?
Mostra risposta
Non c’è modo di sapere cosa è cambiato tra una versione e l’altra, chi ha fatto la modifica e quando. Con molti file e molte persone, diventa impossibile capire quale sia la versione “vera” e si verificano sovrascritture accidentali. Inoltre, non c’è modo di tornare a una versione precedente se non si è salvata una copia manuale — e trovare quella giusta tra decine di copie è un incubo.
2. Qual è la differenza fondamentale tra un VCS centralizzato e uno distribuito?
Mostra risposta
In un VCS centralizzato (es. SVN), la storia completa del progetto esiste solo sul server — ogni sviluppatore ha solo i file di lavoro e deve connettersi al server per qualsiasi operazione di versioning. In un VCS distribuito (es. Git), ogni sviluppatore ha una copia completa del repository, inclusa tutta la storia. Questo significa che puoi lavorare offline, che ogni copia è un backup completo e che le operazioni locali (commit, log, diff, branch) sono istantanee.
3. Git e GitHub sono la stessa cosa?
Mostra risposta
No. Git è un software di controllo versione che gira sul tuo computer — funziona offline e non ha bisogno di Internet. GitHub è un servizio web che ospita repository Git online e aggiunge strumenti di collaborazione: issue, pull request, code review, GitHub Actions e molto altro. Puoi usare Git senza GitHub (e lo farai nelle lezioni 01–06). Non puoi usare GitHub senza Git — ogni operazione su GitHub è basata su Git sotto il cofano.
4. Perché Git memorizza “snapshot” (fotografie) invece di “delta” (differenze)?
Mostra risposta
Con gli snapshot, per ricostruire lo stato del progetto a un certo punto basta prendere direttamente la fotografia corrispondente — operazione istantanea. Con i delta, devi partire dalla versione iniziale e applicare tutte le differenze in sequenza fino al punto desiderato — operazione che diventa lenta man mano che la storia cresce. Git in realtà non duplica i file non modificati: salva un puntatore alla versione precedente. Quindi l’occupazione su disco è comparabile ai sistemi a delta, ma la velocità di accesso è molto superiore.
5. Cosa sono i “tre stati” di Git (working directory, staging area, repository)?
Mostra risposta
La working directory è la cartella del tuo progetto dove modifichi i file normalmente. La staging area è un’area intermedia dove “selezioni” quali modifiche includere nel prossimo commit (con git add). Il repository è il database di Git che contiene la storia permanente di tutti gli snapshot (ci salvi con git commit). Il flusso è: modifichi nella working directory → selezioni con git add → salvi con git commit. La staging area esiste per permetterti di fare commit mirati — non sei obbligato a salvare tutte le modifiche in un unico commit.
6. Un compagno ti dice: “Non mi serve Git, uso Google Drive per condividere i file.” Cosa gli rispondi?
Mostra risposta
Google Drive è ottimo per condividere file, ma non è un sistema di controllo versione. Drive tiene una cronologia delle modifiche limitata nel tempo e non ti permette di: creare branch per lavorare in parallelo senza rischi, fare merge intelligente delle modifiche di più persone, scrivere messaggi che spiegano cosa è cambiato e perché, tornare a qualsiasi versione precedente con un solo comando. Per un documento di testo condiviso, Google Docs può bastare. Ma per un progetto di programmazione con decine di file, o per qualsiasi lavoro dove servono storia dettagliata, lavoro parallelo e rollback affidabili, Git è lo strumento giusto.
📚 Riepilogo della lezione
- Il versioning manuale (copie rinominate) non scala — serve un sistema automatico
- Un VCS registra la storia completa delle modifiche: chi, cosa, quando, perché
- I 4 concetti base: repository (contenitore), commit (snapshot), branch (linea parallela), merge (ricombinazione)
- Centralizzato = un server, sviluppatori dipendenti · Distribuito = ogni copia è completa, lavori offline
- Git = software locale di versioning · GitHub = servizio web di hosting e collaborazione
- Git usa il modello a snapshot (fotografie complete) invece che a delta → velocità istantanea
- I tre stati: working directory → staging area (
git add) → repository (git commit)
Prossima lezione →
Lezione 02 — Installazione e configurazione
Installare Git su Windows, macOS e Linux.git config: nome, email, editor, colori. Il tuo primo setup.
Corso Git & GitHub · Per studenti e insegnanti · Lezione 01 di 45