Il software di version control distribuito Git non ha certo bisogno di presentazioni, qui sul portale abbiamo addirittura coperto una serie in tre puntate che si intitola “Git & Tricks – Pillole di source code management” che introduce lo strumento e promuove alcune best practice:

• Parte 1: un ambiente confortevole
• Parte 2: gestire i commit con empatia
• Parte 3: l’importanza del rebase per un mondo migliore

Altra cosa che non servirebbe ripetere è che è stato creato nel 2005 dal papà di Linux, Linus Torvalds, e lasciato in mano di altri maintainers quasi subito dopo, perché il risultato era stato raggiunto con la creazione di uno standard tutt’oggi utilizzato.

Qualcosa che magari i più ignorano è relativa invece alle release. Dalla sua prima pubblicazione infatti, Git ha solamente avuto due major release, tanto che al momento la versione stabile del progetto è la 2.51, pubblicata lo scorso agosto. Non solo, come recita la pagina intitolata “Breaking Changes” sul sito ufficiale di Git, fino ad oggi ci sono state solo due release che non sono state retro compatibili:

• Git 1.6.0, rilasciata l’agosto del 2008.
• Git 2.0, rilasciata nel maggio del 2014.

Il motivo per cui citiamo tutto questo è che la prossima major release di Git, ossia la 3.0, rientrerà in questa categoria poiché porterà alcuni cambiamenti radicali che difficilmente saranno retro compatibili. Si può già peraltro fare un bilancio di alcune delle funzionalità che verranno introdotte, poiché nel codice sorgente di git queste sono indicate con la valorizzazione di una variabile dall’eloquente nome di WITH_BREAKING_CHANGES.

La più importante è certamente l’utilizzo automatico degli hash a 256 bit, gli SHA-256, come riferimento univoco per i commit. Introdotta lo scorso luglio all’interno di questo commit, questa prevede l’utilizzo del GIT_HASH_SHA256 come default ed in realtà la funzionalità è già testabile proprio andando a impostare la variabile WITH_BREAKING_CHANGES nella configurazione di Git.

Altra aggiunta molto rilevante sarà l’introduzione dello strato di compatibilità con il linguaggio Rust. Così come sta avvenendo per il Kernel Linux infatti, anche per Git è stato avviato il processo di abilitazione per il linguaggio Rust, in modo che gli esperimenti di sviluppo possano partire e che chi utilizza Git (vedi GitHub o GitLab ad esempio) per offrire servizi possa iniziare a capire cosa Rust comporti (viene citato esplicitamente che l’introduzione di Rust è impossibile in alcune piattaforme e difficile in altre).

Quindi con la release 3.0 le build di Git supporteranno obbligatoriamente Rust.

Rimane solo un’ultima domanda: quando uscirà questa importante release? Sarà bene non trattenere il fiato, poiché non è stata ancora pianificata, tanto che la pagina sopra citata indica chiaramente che “There is no planned release date for this breaking version yet“.

Anche se non è difficile capire cosa ci finirà dentro, questa impredittibilità della data di uscita è in linea con il suo creatore il quale, lo sappiamo, è abbastanza allergico ad utilizzare una logica nelle major release del Kernel Linux.

Insomma, Git 3.0 sarà come il Natale, quando arriva, arriva, ma intanto dentro ci sarà certamente un po’ di ruggine.