Cos'è Git e perché ogni sviluppatore deve conoscerlo

Git è un sistema di controllo versione

Git è un programma che tiene traccia della storia delle modifiche ai file di un progetto. Ogni volta che registrate lo stato del codice, Git salva un'istantanea (un commit) con autore, data e descrizione. Potete tornare a qualsiasi istantanea, confrontarla con lo stato attuale, scoprire chi ha cambiato una certa riga e perché.

Se vi è mai capitato di avere cartelle come «progetto_v2», «progetto_finale» e «progetto_finale_DEFINITIVO», avete già fatto controllo versione, solo a mano. Git fa la stessa cosa in automatico, in modo compatto e senza il rischio di perdere qualcosa. Per questo, quando gli sviluppatori parlano di Git, non intendono solo un programma ma uno strumento di lavoro di base, obbligatorio quanto l'editor di codice.

In cosa Git è diverso da una «cartella di copie» o da un cloud drive

Un cloud drive conserva l'ultima versione di un file e, nel migliore dei casi, qualche copia automatica. Git conserva una storia significativa: siete voi a decidere quando registrare le modifiche e a scrivere cosa avete fatto. Inoltre Git sa fare cose che nessun drive sa fare:

• portare avanti più linee di sviluppo contemporaneamente (branch) e unirle;
• mostrare le differenze riga per riga tra versioni (git diff);
• unire le modifiche di persone diverse agli stessi file;
• trovare il commit dopo il quale è comparso un bug (git bisect);
• funzionare senza internet: tutta la storia è in locale sul vostro computer.

Cosa significa il nome Git

Git non ha un significato ufficiale: non è un acronimo. Linus Torvalds ha scelto il nome nel suo stile: nello slang britannico «git» indica una persona sgradevole e testarda. Torvalds scherzava dicendo di dare a tutti i suoi progetti il proprio nome. Tradotto alla lettera, git è qualcosa come «idiota» o «scemo».

Nel primo README del progetto l'autore proponeva alcune interpretazioni scherzose: per esempio «global information tracker» quando tutto funziona, e una variante volgare quando qualcosa si rompe. Quindi, se a un colloquio vi chiedono «per cosa sta Git», la risposta giusta è: per niente, è una parola e non un acronimo.

La pronuncia corretta ha la «g» dura, come in «ghiro»: «ghit», non «gît».

Da dove nasce Git

Fino al 2005 gli sviluppatori del kernel Linux usavano il sistema proprietario BitKeeper. Quando la licenza gratuita per la comunità fu revocata, Torvalds scrisse in poche settimane un sistema tutto suo. I requisiti erano severi: velocità su un progetto enorme, lavoro completamente distribuito, protezione affidabile della storia contro la corruzione e gestione comoda di migliaia di branch paralleli.

Poco dopo la manutenzione del progetto passò a Junio Hamano, che ne è ancora oggi il maintainer. Oggi Git è un sistema open source con licenza GPLv2, e su di esso si basano GitHub, GitLab, Bitbucket, Gitea e molte piattaforme aziendali.

Come funziona Git dietro le quinte

Perché Git smetta di sembrare un insieme di comandi magici, conviene capire tre idee. Spiegano quasi tutto il comportamento del sistema.

1. Istantanee, non differenze

Molti sistemi più vecchi salvavano le modifiche come una serie di patch ai file. Git ragiona per istantanee: ogni commit è lo stato completo del progetto al momento della registrazione. Per non sprecare spazio, i file non modificati non vengono copiati: il commit fa semplicemente riferimento a un oggetto già salvato. Quando impacchetta il repository, Git comprime anche gli oggetti simili, quindi la storia di un progetto anche grande occupa poco spazio.

2. Tutto è indirizzato tramite hash

Ogni oggetto in Git, che sia il contenuto di un file (blob), la struttura di una cartella (tree) o un commit, riceve un identificatore calcolato dal suo contenuto. Storicamente è SHA-1 (40 caratteri esadecimali); nelle versioni recenti si può creare un repository con SHA-256. Modificare di nascosto un vecchio commit è impossibile: cambierebbe il suo hash e quello di tutti i commit successivi.

$ git log --oneline -3
a3f9c21 Aggiungi form di login
7b02e4d Correggi validazione email
1c8d5f0 Primo commit

Le stringhe corte a sinistra sono gli hash abbreviati dei commit. Con questi potete riferirvi a qualsiasi versione: git show 7b02e4d.

3. I tre stati dei file

È la base delle basi di Git, ed è una domanda che compare quasi a ogni colloquio. Un file del progetto può trovarsi in una di tre aree:

L'indice è ciò che distingue Git da molti altri sistemi. Permette di mettere in un commit solo una parte delle modifiche: per esempio la correzione di un bug da una parte e la rinomina delle variabili dall'altra. Così la storia resta leggibile.

Sistema distribuito: perché ognuno ha una copia completa

Git è un sistema di controllo versione distribuito (DVCS). Quando clonate un repository non ricevete solo gli ultimi file, ma tutta la storia del progetto. La maggior parte delle operazioni (commit, consultazione della storia, creazione di un branch, confronto) avviene in locale e all'istante, senza server.

In questo modello un server come GitHub è solo un'altra copia del repository che il team ha concordato di considerare principale. Se non è raggiungibile, il lavoro non si ferma: continuate a fare commit e invierete le modifiche più tardi con git push. Se il server va perso del tutto, la storia si può ricostruire da qualsiasi clone.

Git e GitHub non sono la stessa cosa

È una confusione frequente tra i principianti. Git è un programma che gira sul vostro computer. GitHub è un servizio web che ospita repository Git e offre strumenti per il lavoro di squadra: pull request, code review, issue, CI. GitLab e Bitbucket sono servizi analoghi.

Potete usare Git senza GitHub, per esempio per appunti personali o per un progetto locale. GitHub senza Git invece non ha senso: è costruito interamente attorno ai suoi repository.

Le basi di Git: il ciclo di lavoro minimo

Ecco come appare il lavoro quotidiano. Questi pochi comandi coprono gran parte di ciò che uno sviluppatore fa ogni giorno.

# creare un repository nella cartella corrente
git init

# vedere cosa è cambiato
git status

# aggiungere i file all'indice
git add index.html style.css

# registrare l'istantanea
git commit -m "Impagina la home page"

# vedere la storia
git log --oneline

# creare un branch e passarci
git switch -c feature/login

# unire il branch in quello principale
git switch main
git merge feature/login

# inviare le modifiche al server
git push origin main

Il comando git switch è arrivato con Git 2.23 come sostituto più chiaro di una parte delle funzioni di git checkout. Nelle guide più vecchie troverete git checkout -b feature/login: fa la stessa cosa.

Cosa succede quando fate git commit

Git prende il contenuto dell'indice, salva ogni file come blob, costruisce gli oggetti tree per le cartelle e crea un oggetto commit. Nel commit sono registrati: il riferimento all'albero, il riferimento al commit genitore (o a due, dopo un merge), l'autore, il committer e il messaggio. Poi il puntatore del branch corrente si sposta sul nuovo commit. Un branch in Git è letteralmente un file con l'hash dell'ultimo commit, ed è per questo che i branch si creano in millisecondi.

A cosa serve Git: le ragioni pratiche

Potete sperimentare senza paura

Ogni modifica è reversibile. Avete rotto il codice? git restore file riporta l'ultima versione registrata. Un commit sbagliato è già nella storia? git revert crea un commit inverso senza riscrivere la storia condivisa. Questo cambia il modo di lavorare: osate di più, perché tornare indietro costa pochi secondi.

Lavoro di squadra senza caos

Ogni sviluppatore lavora nel proprio branch senza intralciare gli altri. Quando il task è pronto, le modifiche passano la review e vengono unite nel branch principale. Se due persone hanno toccato lo stesso punto, Git segnala un conflitto e vi lascia risolverlo consapevolmente, invece di sovrascrivere in silenzio il lavoro altrui.

La storia come documentazione

Dei buoni messaggi di commit rispondono alla domanda «perché il codice è fatto così». Il comando git blame file mostra chi ha modificato per ultimo ogni riga e in quale commit, mentre git log -p file mostra l'intera evoluzione del file. A distanza di un anno questo fa risparmiare ore di indagini.

Lo chiedono i datori di lavoro

La conoscenza di Git compare praticamente in ogni annuncio per sviluppatori, tester, DevOps engineer e data analyst. Ai colloqui non si verificano i comandi imparati a memoria, ma la comprensione: in cosa merge differisce da rebase, cos'è l'indice, come annullare un commit, come risolvere un conflitto. E un profilo GitHub con una storia di commit ordinata funziona da portfolio.

A chi altro serve Git

Git è comodo ovunque ci siano file di testo e conti la storia: technical writer (documentazione in Markdown), web designer, analisti (script SQL, notebook), sistemisti (configurazioni dei server, infrastructure as code). Per i file binari di grandi dimensioni (video, PSD, dataset) si usa l'estensione Git LFS, perché Git di per sé è ottimizzato per il testo.

Pro Git: il miglior libro su Git

Se volete approfondire, partite dal libro «Pro Git» di Scott Chacon e Ben Straub. È gratuito, distribuito con licenza aperta e pubblicato sul sito ufficiale git-scm.com nella sezione Book, anche in traduzione in diverse lingue. È un vero manuale, dalle basi fino ai meccanismi interni.

Come leggerlo con profitto:

• capitoli 1–3 (introduzione, basi, branching): il minimo indispensabile, ripetete i comandi nel terminale;
• il capitolo sul lavoro con i repository remoti e GitHub: quando inizierete a lavorare in team;
• il capitolo «Git Internals»: quando vorrete capire davvero come sono fatti oggetti e riferimenti.

Il secondo punto di riferimento ufficiale è la guida integrata: git help commit o git commit --help aprono la documentazione completa del comando, mentre git commit -h mostra un riepilogo rapido delle opzioni.

Gli equivoci tipici dei principianti

• «Git salva i file in automatico». No: finché non fate un commit, le modifiche esistono solo nella directory di lavoro.
• «Il commit finisce subito su GitHub». Il commit è locale. Arriva sul server solo dopo git push.
• «git add serve solo per i file nuovi». git add aggiunge all'indice anche le modifiche ai file già tracciati.
• «Ciò che è stato cancellato dalla storia non si recupera». Quasi sempre si recupera: git reflog conserva gli spostamenti dei puntatori e il commit «perso» si ritrova tramite l'hash.
• «I branch sono copie del progetto». Un branch è un puntatore leggero a un commit, non un duplicato dei file.

Da dove cominciare a studiare Git

1. Installate Git e verificate la versione: git --version.
2. Configurate nome ed email: git config --global user.name e user.email.
3. Create un repository di prova, fate 5–10 commit, guardate git log e git diff.
4. Lavorate con i branch: createli, uniteli, provocate apposta un conflitto e risolvetelo.
5. Create un account GitHub, caricateci il repository e aprite la vostra prima pull request.

Questo ordine dà risultati più in fretta che leggere manuali da cima a fondo: vedete subito come ogni comando cambia lo stato del repository.

In sintesi

Git è un sistema di controllo versione distribuito che conserva la storia del progetto come istantanee, la protegge con gli hash e permette al team di lavorare in parallelo sui branch. Il nome non è un acronimo e, in pratica, cos'è Git si riassume così: uno strumento obbligatorio per qualsiasi sviluppatore. Imparate il ciclo add, commit, push, capite le tre aree dei file e i branch, poi approfondite con il libro Pro Git. Tutto questo, passo dopo passo, dal primo commit alla pull request, è affrontato in pratica nel corso su Git.