Tagging & Versioning in Git


Lezione 51 / 53

Tagging & Versioning in Git

Di Luca Ferretti


git guida git guida git italiano

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)

Guida Git in italiano 1 Che cos'è Git? 2 Nascita di Git 3 Principali caratteristiche di Git 4 Riga di comando e UI in Git 5 Come Installare Git 6 5 comandi Git per sviluppatori singoli 7 5 comandi Git per sviluppare collaborando 8 Repository in Git 9 Commit in Git 10 Working Copy in Git 11 Staging Area in Git 12 Branch in Git 13 Remote in Git 14 Inizializzare un nuovo repository con git init 15 Creare una copia di un repository remoto in Git con git clone 16 Configurare le opzioni di Git con git config 17 Il comando Git add in Git 18 Il comando Git commit in Git 19 Il comando Git diff in Git 20 Il comando Git stash in Git 21 .gitignore : i file ignored in Git 22 Il comando Git status in Git 23 il comando Git log in Git 24 Il comando Git tag in Git 25 Il comando Git blame in Git 26 Il comando Git checkout in Git 27 Il comando Git revert in Git 28 Il comando Git reset in Git 29 Il comando Git rm in Git 30 L'opzione Git commit –amend in Git 31 Git rebase –interactive in Git 32 Scorciatoie per comandi frequenti in Git 33 Repository condiviso in Git 34 Il modello Fork & pull 35 Il comando Git remote in Git 36 I principali repository remote di Git: Github, Gitlab e Bitbucket 37 Il comando Git fetch in Git 38 Il comando Git push in Git 39 Il comando Git pull in Git 40 Il comando Git branch in Git 41 Il comando Git checkout in Git 42 Il comando Git merge in Git 43 Risolvere un merge conflict in Git 44 Capire meglio il contenuto dei commit durante un conflitto di merge in Git 45 Workflow Git centralizzato 46 Workflow Git feature branching 47 Workflow Git trunk-based 48 Approccio “forking” in Git 49 Gitflow in Git 50 Messaggi di commit in Git 51 Tagging & Versioning in Git 52 L’opzione merge in Git 53 L’opzione rebase in Git
Scopri i corsi

Le nostre guide possono essere molto utili per muovere i primi passi nel mondo della programmazione, ma se vuoi iniziare una nuova carriera in ambito digital & tech con il supporto costante dei docenti e tantissime esercitazioni pratiche, ti consigliamo di frequentare uno dei corsi della nostra Hackademy!

Scopri i corsi