La rottura con BitKeeper
Per anni il kernel Linux è stato gestito con BitKeeper, un sistema di controllo di versione proprietario concesso gratuitamente alla comunità. Quando nel 2005 la licenza gratuita viene revocata, Linus Torvalds decide di scrivere da zero uno strumento che risponda alle esigenze reali dello sviluppo distribuito su larga scala. In circa due settimane nasce Git, un sistema di controllo di versione distribuito (DVCS) che rovescia i presupposti dei sistemi centralizzati come CVS e Subversion.
L’obiettivo dichiarato è la velocità: il kernel Linux conta migliaia di file e centinaia di sviluppatori sparsi nel mondo. Un sistema centralizzato, con un singolo server che detiene la storia completa, introduce colli di bottiglia nella rete e single point of failure. Git elimina entrambi i problemi.
Architettura e integrità
Ogni clone di un repository Git è una copia completa dell’intera storia del progetto. Non esiste distinzione architetturale tra server e client: ogni copia è un repository a tutti gli effetti, capace di operare offline e di sincronizzarsi successivamente con altri repository.
Git modella la storia come un DAG (directed acyclic graph) di commit, ciascuno dei quali punta a uno snapshot completo dell’albero dei file — non a una lista di differenze. Ogni oggetto nel repository — commit, alberi, blob — è identificato dal proprio hash SHA-1, che funge contemporaneamente da nome e da checksum di integrità. Se anche un singolo bit cambia, l’hash cambia, rendendo immediatamente evidente qualsiasi corruzione o manomissione.
Branching e merge
Nei sistemi centralizzati, creare un branch è un’operazione costosa che spesso scoraggia la sperimentazione. In Git, un branch è semplicemente un puntatore mobile a un commit: crearlo costa quanto scrivere quaranta caratteri in un file. Questo rende il branching un’operazione quotidiana piuttosto che eccezionale.
Il modello di merge si basa sull’analisi dei DAG: Git individua l’antenato comune di due branch e applica un merge a tre vie. Quando le modifiche non si sovrappongono, il processo è automatico. I conflitti vengono segnalati in modo esplicito, lasciando allo sviluppatore il controllo sulla risoluzione.
Un cambio di paradigma
Git introduce un modo diverso di pensare al controllo di versione. Ogni sviluppatore lavora nel proprio repository locale, effettua commit frequenti senza impattare gli altri e condivide le modifiche solo quando sono pronte. La storia è immutabile, verificabile, e distribuita. Per il kernel Linux e per la comunità open source in generale, è l’inizio di una nuova era nella gestione collaborativa del codice sorgente.
Link: git-scm.com