Tagging & Versioning in Git

Sempre considerando che Git in sé non è prescrittivo nell’uso dei tag - sono etichette che puntano a un singolo commit - per una gestione efficiente di un progetto è opportuno definire alcune guideline relative all’uso dei tag in Git.

Possiamo dire che i tag di Git sono abitualmente usati per indicare una determinata versione o rilascio del software. Le modalità specifiche possono dipendere da progetto a progetto. Per esempio, progetti che prevedono che la versione corrente sia salvata in un certo file possono avere un commit in cui viene salvata la versione e aggiungere a tale commit un tag con la stessa versione. Altri progetti possono taggare un commit qualsiasi come versione (ricordiamo sempre che un commit è uno snapshot).

In modo simile a quanto visto poco sopra per i conventional commit, anche per il versionamento di un progetto software esistono diverse convenzioni, una di quelle più note è il semantic versioning o semver.

Nel semantic versioning la versione è rappresentata da tre numeri, separati da un punto, ciascuno dei quali rappresenta come il nuovo rilascio o versione è cambiato rispetto al precedente, in particolare:

• il primo numero la major version, da incrementare quando il cambio non è retrocompatibile
• il secondo numero è la minor version, da incrementare quando si aggiungono funzioni ma è ancora retrocompatibile
• il terzo numero è la patch version, da incrementare quando si correggono bug in modo retrocompatibile

Con questa convenzione possiamo quindi capire che:

• 0.2.0 - è un progetto nelle fasi iniziali di sviluppo (la versione major è 0), non è detto che cambierà in modo compatibile
• 1.0.0 - è la prima versione “ufficiale”
• 1.0.3 - è il terzo rilascio di fix della versione 1.0, non ci sono nuove funzioni rispetto alla 1.0, ma solo correzione di errori
• 1.1.0 - è il primo rilascio con nuove funzioni della versione 1, ma ancora compatibile con la versione 1
• 2.0.0 - è il primo rilascio non più compatibile con la versione 1
• 2.1.0-alpha.1 - è un pre-rilascio della futura versione 2.1.0

Maggiori informazioni sul semantinc versioning possono essere trovate su Semver.

Dal punto di vista dei tag Git, nel caso in cui si seguisse il semantic versioning, il suggerimento è quello di usare come tag il numero di versione con davanti la lettera v. I tag in questo caso sarebbero quindi v0.2.0, v1.0.3, v1.1.0, v2.1.0-alpha.1 e così via.

Ovviamente, i tag Git sono utili a contrassegnare quale commit (e quindi quale snapshot della codebase) corrisponde a una certa versione o rilascio, ma per poter eventualmente mantenere due “linee di sviluppo” (per esempio, lavorare alla versione 2 mentre si continua a fornire supporto alla versione 1) sarà necessario trovare altre modalità e workflow basate su altre funzioni di Git (per esempio, i branch)