Cos'è il version control e perché serve davvero

Chiunque abbia lavorato su un file importante conosce la cartella con dentro progetto_finale, progetto_finale_v2, progetto_finale_DEFINITIVO e progetto_finale_DEFINITIVO_ok. È un sistema di controllo di versione, solo fatto malissimo. In questo articolo ti spiego cosa fa quello vero, quali problemi risolve e perché serve anche se lavori da solo.

Cos'è il version control

Un sistema di controllo di versione registra ogni modifica fatta a un insieme di file nel tempo, permettendo di vedere cosa è cambiato, chi l'ha cambiato, quando e perché — e di tornare a qualunque stato precedente.

Non è un backup: un backup conserva una fotografia. Il controllo di versione conserva la storia completa e la rende navigabile.

I quattro problemi che risolve

1. Tornare indietro senza paura

Hai modificato qualcosa e adesso non funziona più niente. Senza controllo di versione, l'unica opzione è ricordarsi cosa si è toccato.

Con il controllo di versione torni allo stato di ieri in pochi secondi. La conseguenza pratica è più grande di quanto sembri: smetti di aver paura di sperimentare. Chi sa di poter annullare tutto prova soluzioni che altrimenti non proverebbe.

2. Sapere cosa è successo e perché

Ogni modifica registrata porta con sé un messaggio che ne spiega il motivo. Tra sei mesi, davanti a una riga di codice incomprensibile, puoi risalire a quando è stata scritta e leggere la spiegazione di chi l'ha scritta.

È l'unica forma di documentazione che non diventa mai obsoleta, perché è legata al cambiamento stesso.

3. Lavorare in più persone senza pestarsi i piedi

Senza uno strumento, due persone che modificano lo stesso file si sovrascrivono a vicenda. Il controllo di versione permette di lavorare in parallelo e poi unire le modifiche, segnalando i punti in cui entrano davvero in conflitto.

4. Lavorare su più cose insieme

Puoi tenere separate una correzione urgente e una funzionalità in sviluppo, e passare dall'una all'altra senza mescolarle. È il concetto di ramo, di cui parlo tra poco.

Come funziona Git

Git è oggi lo standard di fatto, al punto che "controllo di versione" e "Git" vengono usati come sinonimi. Vale la pena capire i tre concetti che lo governano.

Il commit: una fotografia con un motivo

Un commit è uno stato salvato del progetto, con un messaggio che spiega cosa è cambiato e perché.

Non salvi un file: salvi uno stato coerente dell'insieme. È l'unità base della storia.

Il ramo: una linea di sviluppo parallela

Un ramo è una linea di lavoro indipendente, che parte da un certo punto della storia e prosegue per conto suo.

Il modello tipico: il ramo principale contiene il codice funzionante, e ogni nuova funzionalità viene sviluppata su un ramo a parte, per poi essere riunita al principale quando è pronta.

In Git creare un ramo è un'operazione istantanea, ed è il motivo per cui ha vinto sui sistemi precedenti, dove era un'operazione pesante che si evitava.

Distribuito: ognuno ha tutto

Questa è la differenza concettuale più importante rispetto ai sistemi vecchi.

Nei sistemi centralizzati esisteva un server con la storia, e le copie locali erano solo istantanee. Senza connessione al server non potevi fare quasi nulla.

In Git ogni copia contiene la storia completa. Puoi lavorare, salvare, creare rami e consultare tutto lo storico senza connessione. Il server condiviso — GitHub, GitLab o altri — è solo un punto di incontro concordato, non il custode della verità.

Ne consegue anche che ogni copia è, di fatto, un backup completo della storia del progetto.

Serve anche se lavoro da solo?

Sì, e probabilmente è la cosa che chi impara sottovaluta di più.

I benefici che valgono anche in solitaria:

• Sperimentare senza rischio. Provi un approccio diverso su un ramo; se non funziona, lo butti.
• Capire cosa hai rotto. Funzionava ieri e oggi no: guardi cosa è cambiato in mezzo.
• Ricordarti perché. Il tuo io di sei mesi fa è, a tutti gli effetti, un'altra persona.
• Il progetto vive anche se il computer muore.
• È un requisito professionale. Nessuno ti assume senza: fa parte del mestiere quanto saper scrivere codice. E un profilo con progetti versionati è metà del lavoro di un portfolio.

Il momento giusto per iniziare a usarlo è il primo giorno, non quando il progetto diventa "serio". Prendere l'abitudine su un progetto piccolo costa niente; impararlo su un progetto grande e disordinato è molto più difficile.

Cosa versionare e cosa no

Va versionato: il codice, i file di configurazione del progetto, la documentazione, gli script, l'elenco delle dipendenze.

Non va versionato:

• Le dipendenze installate. Si reinstallano dall'elenco: metterle nel repository lo appesantisce inutilmente.
• I file generati — risultati di compilazione, cache.
• I file dell'ambiente di lavoro — impostazioni personali dell'editor, file di sistema.
• I file di grandi dimensioni — Git è pensato per il testo, non per video e archivi.

E soprattutto: mai le credenziali. Chiavi API, password, certificati. È l'errore più grave e più frequente, e ha un aggravante da conoscere: rimuovere un segreto in un commit successivo non lo cancella dalla storia. Resta lì, leggibile da chiunque abbia accesso al repository, e va considerato compromesso — cioè da revocare e sostituire, non solo da togliere.

Per questo esiste un file di esclusioni che dice a Git cosa ignorare, e va impostato all'inizio del progetto.

Non solo per il codice

Vale la pena saperlo, perché allarga parecchio l'utilità:

Documentazione e testi. Se scrivi in formato testuale, il controllo di versione funziona benissimo — questo sito ne è un esempio. È anche il meccanismo dietro il deploy automatico di un sito: invii una modifica e il sito si aggiorna.

Configurazioni di infrastruttura. L'approccio di descrivere i server in file versionati nasce proprio da qui.

Contenuti e dati strutturati. Qualunque cosa sia testo e cambi nel tempo.

Il limite: Git confronta il testo riga per riga. Su file binari — immagini, documenti di grafica, video — può conservarli ma non mostrarti cosa è cambiato, e li fa pesare parecchio.

Le alternative

Esistono altri sistemi, e capire perché Git domina aiuta:

Mercurial — concettualmente simile, considerato più semplice, con una comunità molto più piccola.

Subversion (SVN) — centralizzato, ancora presente in aziende con codebase storiche. Gestisce meglio i file binari di grandi dimensioni.

Perforce — diffuso nello sviluppo di videogiochi, proprio perché gestisce bene enormi quantità di file binari.

Ma per il 95% dei progetti la risposta è Git, e la ragione principale non è tecnica: è che lo usano tutti. Strumenti, servizi e persone si sono adattati attorno a lui.

In sintesi

Il controllo di versione registra la storia delle modifiche di un progetto e la rende navigabile: puoi tornare indietro, capire cosa è cambiato e perché, e lavorare in parallelo senza sovrascrivere il lavoro altrui.

Git è lo standard, ed è distribuito: ogni copia contiene la storia completa e funziona senza connessione. I suoi concetti base sono due — il commit (uno stato salvato con un motivo) e il ramo (una linea di lavoro parallela).

Serve anche se lavori da solo, e il momento giusto per iniziare è il primo giorno di un progetto, non quando diventa importante.

E la regola che evita il danno più grave: mai mettere credenziali in un repository — perché la storia non si cancella riscrivendo il presente.

Se vuoi passare dalla teoria alla pratica, la guida operativa è in come usare Git e GitHub.