Il problema che risolve il controllo di versione

Un sistema di controllo di versione (version control system, o VCS) tiene traccia della storia delle modifiche mentre persone e team collaborano allo stesso progetto. Senza, un gruppo che lavora sugli stessi file convive con tre problemi ricorrenti: nessuno sa quale sia la versione buona, nessuno sa chi ha introdotto una certa modifica né perché, e tornare indietro dopo un errore significa sperare che qualcuno abbia tenuto una copia.

Un VCS li risolve tutti e tre perché registra ogni modifica come un commit: una fotografia dello stato del progetto, con un identificativo univoco, un autore, un momento nel tempo e un messaggio che ne spiega l’intento. La cronologia diventa così interrogabile: che cosa è cambiato, chi lo ha cambiato, quando e perché. Da lì discendono i benefici che l’esame si aspetta tu sappia elencare: storia completa e tracciabile, ripristino di qualsiasi stato precedente, lavoro in parallelo tramite branch (una versione parallela del repository che non disturba il ramo principale), attribuzione chiara delle responsabilità e una base solida su cui costruire revisione del codice e automazione.

Perché non è un backup, e perché non blocca i file

Due equivoci vanno smontati subito.

Il primo: un VCS non è un backup. Un backup conserva una copia dei file a un certo istante e serve a rimettere tutto com’era dopo un guasto. Il controllo di versione conserva invece la sequenza delle decisioni: non solo il “com’era”, ma chi, quando, con quale intento, e la possibilità di annullare una singola modifica lasciando intatte tutte le altre. Un backup risponde a “ho perso i dati”; il controllo di versione risponde a “chi ha rotto questa funzione e come torno indietro solo su quella”. Che poi la cronologia sia replicata altrove è un effetto collaterale utile, non lo scopo.

Il secondo: Git non serializza gli accessi ai file. In alcuni strumenti di versionamento più vecchi chi apriva un file lo bloccava con un check-out esclusivo e gli altri aspettavano il rilascio. Non è così che funziona qui: più persone possono lavorare contemporaneamente sugli stessi file, ciascuna sul proprio branch, e le divergenze si affrontano solo al momento dell’unione, risolvendo un merge conflict quando davvero si presenta. Il lavoro in parallelo è la regola, non l’eccezione.

Centralizzato contro distribuito

In un modello centralizzato la cronologia vive su un server centrale: per registrare una modifica, consultare la storia o creare un ramo serve una connessione costante a quel server. Se il server non è raggiungibile, il lavoro versionato si ferma.

Git è invece un sistema di controllo di versione distribuito, ed è il più diffuso. Chi esegue un clone di un repository ottiene sul proprio computer una copia completa del progetto e della sua intera cronologia. Da quel momento può fare commit, creare branch e leggere la storia in locale, anche senza rete. La copia condivisa ospitata su un server si chiama remote e per convenzione quello predefinito prende il nome origin: con push si inviano i propri commit al remote, con pull si recuperano quelli degli altri.

Dove finisce Git e dove comincia GitHub

Git è il programma che gira sulla tua macchina e fa il versionamento. GitHub è la piattaforma che ospita i progetti Git nel cloud — chiamati repository — e ci costruisce sopra pianificazione, collaborazione, sicurezza e automazione, coprendo l’intero processo di sviluppo software, dalla pianificazione fino al rilascio e all’esercizio. Un repository è l’elemento base di GitHub: contiene i file del progetto, documentazione inclusa, e la cronologia delle revisioni di ciascun file.

Ne segue la regola pratica: Git funziona benissimo senza GitHub. Puoi inizializzare un repository su un portatile scollegato da Internet e versionare per anni senza alcun account, oppure usare Git con un servizio di hosting diverso. Viceversa issue, pull request, code review, fork (la copia personale del repository di un altro utente sul tuo account) e le automazioni non sono comandi Git: sono funzionalità della piattaforma.

Attenzione infine a GitHub Desktop: è un’applicazione gratuita e open source, con interfaccia grafica, che semplifica i comandi Git e aiuta a visualizzare le modifiche, e lavora con file ospitati su GitHub oppure su altri servizi di hosting Git. È dunque un client, un’alternativa alla riga di comando: non è GitHub, e non è nemmeno Git.

Che cosa verifica l’esame. Su questo obiettivo GH-900 chiede di descrivere scopo e benefici del controllo di versione e di spiegare la differenza fra Git e GitHub. Le confusioni più punite: attribuire a Git funzioni che sono della piattaforma; scambiare il comando git pull (scarica dal remote) con una pull request (proposta di modifica da rivedere su GitHub); confondere clone, che è Git, con fork, che è GitHub; e trattare GitHub Desktop come se fosse la piattaforma.