Git: Gestione dei Tag (Tagging)

Come nella maggior parte dei sistemi di controllo versione (VCS), Git consente di associare un’etichetta (tag) a specifici punti della cronologia di un repository.

Questa funzionalità è comunemente utilizzata per identificare rilasci ufficiali del software (ad esempio v1.0, v2.0, ecc.), ma può anche servire a marcare revisioni significative per motivi organizzativi o di audit.

1. Elenco dei Tag Esistenti

Per visualizzare i tag presenti in un repository Git, il comando di riferimento è:
git tag

FIG 1 - Visualizza tag presenti

L’output mostra i tag in ordine alfabetico. L’ordinamento non riflette la sequenza temporale dei rilasci o la loro importanza, ma è puramente lessicografico.

Nei progetti complessi, il numero di tag può essere molto elevato (il repository ufficiale di Git, ad esempio, contiene centinaia di etichette).

Per filtrare i risultati in base a un criterio, è possibile utilizzare le opzioni -l o --list insieme a una wildcard.

Esempio

Se si desidera visualizzare esclusivamente i tag relativi alla versione 4.7, si può eseguire:

$ git tag -l "v4.7*"

FIG 2 - Filtrare i tag

Nota Importante

L’utilizzo di git tag senza argomenti restituisce implicitamente l’elenco completo dei tag.
Se invece si utilizza un pattern (ad esempio "v4.7*"), è obbligatorio specificare -l o --list.

2. Tipologie di Tag in Git

Git mette a disposizione due principali categorie di tag:

• Leggeri (lightweight tag).
• Annotati (annotated tag).

Entrambe le tipologie servono a collegare un commit a un’etichetta significativa, ma si differenziano profondamente in termini di struttura, metadati e finalità d’uso.

Tag Annotati (Annotated Tags)

I tag annotati sono oggetti completi, salvati nel database di Git con un proprio checksum.

Caratteristiche principali:

• Contengono metadati come autore (tagger), email, data.
• Includono un messaggio di tagging, utile per descrivere lo scopo o il contenuto della release.
• Possono essere firmati digitalmente con GNU Privacy Guard (GPG) per garantire autenticità e integrità.
• Sono generalmente considerati la scelta raccomandata per i rilasci ufficiali.

I tag annotati rappresentano la modalità più completa e raccomandata per contrassegnare uno specifico punto nella storia di un repository Git. Essi non solo puntano a un commit, ma contengono anche metadati aggiuntivi che ne arricchiscono l’informazione e ne garantiscono l’autenticità.

Per creare un tag annotato, si utilizza l’opzione -a del comando git tag, accompagnata da un messaggio descrittivo tramite l’opzione -m.

Esempio

git tag -a v1.0 -m "Release ufficiale versione 1.0"

FIG 3 - Creazione di un Tag Annotato

Per ottenere dettagli su un tag annotato, incluso il commit a cui si riferisce, si utilizza il comando git show.

git show v1.0

FIG 4 - git show

Come si può notare, l’output mostra:

• informazioni sul tag (nome, autore del tag, email, data, messaggio di annotazione),
• dettagli sul commit associato (hash, autore, data, messaggio del commit).

Vantaggi dei Tag Annotati

• Tracciabilità: contengono informazioni su chi ha creato il tag e quando.
• Documentazione: permettono di associare un messaggio descrittivo che contestualizza la versione.
• Sicurezza: possono essere firmati digitalmente con GPG, garantendo autenticità e integrità.
• Professionalità: sono la scelta ideale per marcare rilasci ufficiali o milestone significative.

Tag Leggeri (Lightweight Tags)

Oltre ai tag annotati, Git consente la creazione di tag leggeri (lightweight tags), una modalità più semplice e meno strutturata per marcare uno specifico commit nella storia del repository.

A differenza dei tag annotati, i tag leggeri non includono metadati aggiuntivi: essi rappresentano semplicemente un puntatore diretto a un commit, equivalente a salvare l’hash di quel commit in un riferimento con un nome leggibile.

Un tag leggero rappresenta il tipo più semplice di tag in Git.

• È sostanzialmente un puntatore immutabile a un commit specifico, molto simile a un branch che non evolve.
• Non contiene metadati aggiuntivi: né autore, né data, né messaggio.
• È utile per:
  - contrassegnare rapidamente una revisione
  - definire marcature temporanee
  - operazioni di test o debugging.

Per creare un tag leggero è sufficiente eseguire il comando git tag specificando il nome del tag, senza utilizzare le opzioni -a (annotato), -s (firmato) o -m (messaggio). 

Esempio

git tag v1.0.0

In questo caso, il tag v1.0.0 punta semplicemente al commit corrente, senza ulteriori informazioni.

A differenza dei tag annotati, l’uso di git show su un tag leggero non fornisce informazioni aggiuntive (autore del tag, data, messaggio). Mostra esclusivamente i dettagli del commit a cui il tag fa riferimento.

3. Aggiungere un Tag retroattivamente in Git

In alcuni casi può accadere di dimenticare di creare un tag al momento opportuno, ad esempio in corrispondenza di un rilascio o di una milestone importante. Fortunatamente, Git consente di aggiungere un tag retroattivo a un commit già presente nella cronologia, anche se non si tratta dell’ultimo.

Scenario di Partenza

Supponiamo che la cronologia dei ommit sia simile a quella mostrata in FIG 5 dal comando

git log --pretty=oneline

FIG 5 - git log --pretty=oneline

Supponiamo di voler aggiungere un tag alla versione v1.0, corrispondente al commit con messaggio Modifica Projects1.cs  (hash abbreviato 925e858).

Per creare un tag annotato riferito a un commit precedente, è sufficiente specificarne l’hash (anche parziale, purché univoco) al termine del comando:

git tag -a v1.0 925e858 -m "version 1.0"

FIG 6 - Creazione del Tag Retroattivo

Per ottenere informazioni dettagliate sul tag e sul commit associato, è possibile usare:

git show v1.0

FIG 7 - git show

L’output mostra sia i metadati del tag (autore, data, messaggio) sia i dettagli del commit referenziato.

4. Condivisione dei Tag in Git

Per impostazione predefinita, il comando git push non trasferisce automaticamente i tag al repository remoto. Pertanto, una volta creati, è necessario eseguire un’operazione esplicita di push per renderli disponibili ad altri collaboratori. Questo comportamento differisce dai branch, i quali vengono aggiornati automaticamente in seguito a un push.

Pubblicazione di un Singolo Tag

Per condividere un tag specifico con il server remoto, si utilizza la seguente sintassi:

git push origin <tagname>

Ad esempio:

git push origin v1.0

FIG 8 - Push di un singolo tag

In questo esempio, il tag v1.0 viene trasferito correttamente sul repository remoto origin.

Pubblicazione di Tutti i Tag

Qualora sia necessario trasferire più tag contemporaneamente, Git fornisce l’opzione --tags, che invia tutti i tag locali non ancora presenti sul server remoto:

git push origin --tags

FIG 9 - Push di tutti i tag

Dopo questa operazione, chiunque effettui un git clone o un git pull riceverà anche tutti i tag pubblicati.

Differenze tra Tipologie di Tag

È importante ricordare che:

• Il comando git push invia sia i tag lightweight che quelli annotati.
• Per trasferire solo i tag annotati, è possibile utilizzare l’opzione --follow-tags:
  git push origin --follow-tags
  In questo modo, vengono pubblicati soltanto i tag associati a commit presenti nella cronologia del push e che siano stati creati come tag annotati.

Verificare tag disponibili sul repository remoto

Per verificare i tag disponibili sul repository remoto dopo un push, è possibile utilizzare il comando

git ls-remote --tags origin

 

FIG 10 - Tag presenti sul repository remoto

5. Eliminazione dei Tag in Git

In Git, i tag possono essere eliminati sia localmente che sul repository remoto. È importante distinguere le due operazioni, poiché la rimozione in locale non influisce automaticamente sul server remoto, e viceversa.

Eliminazione di un Tag Locale

Per eliminare un tag nel repository locale, si utilizza il comando:

git tag -d <tagname>

Ad esempio:

git tag -d v1.0-lw

FIG 11 - Eliminazione di un tag locale

In questo caso, il tag v1.0-lw viene eliminato solo dal repository locale.

Tuttavia, se il tag era già stato pubblicato su un remoto (es. origin), esso continuerà ad esistere sul server finché non verrà rimosso manualmente.

Eliminazione di un Tag Remoto

Per rimuovere un tag da un repository remoto, Git mette a disposizione due approcci.

1. Utilizzo della sintassi con refs/tags
   git push <remote> :refs/tags/<tagname>
   
   Esempio
   git push origin :refs/tags/v1.0-lw
   
   In questa sintassi, il valore nullo (:) viene "spinto" verso il riferimento remoto del tag, ottenendo come effetto la sua cancellazione.
   
   

   

   FIG 12 - Eliminazione di un Tag Remoto refs-tags

   
   
2. Utilizzo dell’opzione --delete (più intuitivo)
   git push <remote> --delete <tagname>
   
   Esempio:
   git push origin --delete v1.0.1
   
   
   Questa modalità è generalmente preferita, poiché risulta più leggibile e intuitiva rispetto alla precedente.
   
   

   

   FIG 13 - Eliminazione di un Tag Remoto --delete

   
   

6. Visualizzazione del Contenuto di un Tag con git checkout

In Git, i tag rappresentano riferimenti immutabili a specifici commit. Per visualizzare lo stato del progetto associato a un determinato tag, è possibile utilizzare il comando:

git checkout <tagname>

Ad esempio:

git checkout v1.0

FIG 14 - git checkout

Lo stato Detached HEAD

Effettuando un checkout diretto su un tag, Git posiziona il repository in modalità detached HEAD.

In questo stato:

1. È possibile esplorare i file e compilare il progetto esattamente come era al momento del commit taggato.
2. È consentito creare commit, ma questi non saranno collegati ad alcun branch, risultando raggiungibili solo tramite il loro hash SHA.
3. Se si esegue un nuovo git checkout senza aver salvato i commit, le modifiche saranno difficilmente recuperabili.

Esempio:

git checkout v1.0.1

FIG 15 - git checkout

Creazione di un Branch a partire da un Tag

Per lavorare su una versione storica (ad esempio correggere un bug in una release precedente), è consigliato creare un branch derivato dal tag:

git checkout -b <branchname> <tagname>

Esempio:

git checkout -b version2 v2.0

FIG 16 - Creazione di un Branch a partire da un Tag

In questo caso, il nuovo branch version2 viene creato a partire dal commit identificato dal tag v2.0. Eventuali nuovi commit saranno tracciati da questo branch e non andranno persi.

È importante ricordare che il branch si evolverà in maniera indipendente rispetto al tag:

• Il tag rimarrà un riferimento statico al commit originale.
• Il branch potrà avanzare con nuovi commit.

Git: Gestione dei repository remoti

Per collaborare efficacemente in un progetto Git, è fondamentale comprendere come gestire i repository remoti. I repository remoti sono versioni dei progetti ospitati su un server (Internet, rete locale o persino la stessa macchina, purché in un percorso distinto).

La gestione dei remoti comprende operazioni quali:

• Aggiungere o rimuovere repository remoti.
• Consultare la loro configurazione.
• Sincronizzare i dati tramite fetch, pull e push.
• Ispezionare e mantenere aggiornate le referenze remote.

Visualizzare i repository remoti 

Per verificare quali repository remoti sono attualmente associati a un progetto Git, è possibile utilizzare il comando:

git remote

Tale comando restituisce l’elenco degli alias (shortname) configurati per i repository remoti. Qualora il repository sia stato clonato da un server remoto, sarà presente almeno l’alias origin, che costituisce la denominazione predefinita attribuita da Git al repository di origine del clone.

FIG 1 - Git remote

Per ottenere, oltre ai nomi, anche gli indirizzi URL associati ai repository remoti (distinti per operazioni di fetch e push), è possibile utilizzare l’opzione -v:

git remote -v

FIG 2 - git remote -v

Un progetto con più collaboratori può avere vari remoti, ciascuno con il proprio URL e protocollo di accesso (HTTPS, SSH, Git).

Aggiungere un nuovo repository remoto

Per aggiungere un nuovo repository remoto e assegnargli un shortname (alias):

git remote add <shortname> <url>

Esempio:

git remote add pd24 https://github.com/Pedestrian24/Hello.git

Da questo momento, sarà possibile richiamare il repository remoto con pd24 invece di digitare l’intero URL.

FIG 3 - git remote add

Sincronizzazione con Repository Remoti: Fetch e Pull

Nell’ambito della collaborazione su progetti Git, una delle operazioni fondamentali consiste nel mantenere il proprio repository locale aggiornato rispetto al repository remoto. A tal fine, Git mette a disposizione due comandi principali: git fetch e git pull.

1. git fetch: Recupero dei dati senza integrazione automatica

Scarica i nuovi dati dal remoto senza modificarne l’integrazione nel branch attuale. Il comando:

git fetch <remote>

provvede a contattare il repository remoto specificato (ad esempio origin) e a scaricare tutte le nuove informazioni (commit, branch, tag) che non sono ancora presenti localmente.

Dopo l’esecuzione di git fetch, il repository locale contiene riferimenti aggiornati a tutti i branch remoti (ad esempio origin/main, origin/dev, ecc.), senza tuttavia modificare il contenuto della working directory o del branch corrente.

Pertanto:

• I dati vengono aggiornati nella copia locale del database Git.
• Non viene modificato il codice attualmente in lavorazione.
• L’integrazione delle modifiche (mediante merge o rebase) deve essere eseguita manualmente dall’utente.

Esempio pratico:

git fetch origin

Scarica dal server remoto origin tutte le modifiche effettuate da altri collaboratori dall’ultimo fetch, lasciando intatto lo stato della propria area di lavoro.

FIG 4 - git fetch origin

2. git pull: Recupero e fusione automatica

Il comando:

git pull <remote> <branch>

rappresenta una scorciatoia che combina due operazioni:

• git fetch
  recupera i dati aggiornati dal repository remoto.
• git merge (o git rebase se configurato)
  integra automaticamente i dati recuperati nel branch locale attualmente attivo.

In caso di repository clonato con il comando git clone, Git configura automaticamente il branch locale predefinito (main o master, a seconda della nomenclatura del server) per tracciare il branch remoto corrispondente (origin/main o origin/master).

Pertanto, il semplice comando:

git pull

provvede a scaricare e integrare nel branch locale eventuali modifiche presenti sul server remoto di origine.

FIG 5 - git pull

A partire da Git 2.27, se la variabile di configurazione pull.rebase non è impostata, l’esecuzione di git pull genera un avviso, invitando l’utente a scegliere un comportamento predefinito

Configurazioni consigliate:

• Comportamento standard (merge)
  git config --global pull.rebase "false"   
  In questo caso, git pull tenta un fast-forward quando possibile, altrimenti effettua un merge commit.
• Comportamento alternativo (rebase)
  git config --global pull.rebase "true"   
  In questo scenario, le modifiche locali vengono riallineate sopra la cronologia del branch remoto, mantenendo una storia più lineare e priva di commit di merge superflui.

Pubblicazione delle Modifiche su Repository Remoti (Push)

Una volta raggiunto uno stato stabile del proprio progetto locale, è necessario condividere le modifiche con gli altri collaboratori pubblicandole su un repository remoto.

Questa operazione viene eseguita tramite il comando:

git push <remote> <branch>

Concetto di Push

Il comando git push invia i commit presenti nel branch locale specificato verso il corrispondente branch remoto.

Ad esempio, per pubblicare il contenuto del branch main(o master, a seconda della nomenclatura utilizzata) sul repository remoto di default origin, è sufficiente eseguire:

git push origin main

In questo modo, lo stato corrente del branch locale master viene replicato nel corrispondente branch remoto origin/main.

Requisiti e condizioni per il push

L’operazione di push ha successo solo se:

• L’utente dispone di permessi di scrittura sul repository remoto.
• La cronologia del branch remoto è compatibile con quella del branch locale.

Nel caso in cui un altro collaboratore abbia già eseguito un push al branch remoto dopo il vostro ultimo aggiornamento locale, Git rifiuterà l’operazione per evitare la perdita o la sovrascrittura dei commit altrui.

Sincronizzazione prima del push

Quando il push viene rifiutato a causa di divergenze, è necessario:

1. Eseguire un fetch per recuperare i commit remoti:
   git fetch origin 
2. Integrare tali modifiche nel branch locale, utilizzando:
   git merge origin/main
   fusione classica, mantiene entrambe le linee di sviluppo.
   git rebase origin/main
   riallineamento lineare, utile per cronologie pulite.
   
3. Eseguire nuovamente il push:
   git push origin main

Solo dopo questa integrazione sarà possibile completare la pubblicazione delle modifiche.

Scenari avanzati

1. Push di tutti i branch locali:
   git push --all origin
   
2. Pubblicazione dei tag (per versionamento o release):
   git push origin --tags
   
3. Forzare il push (operazione rischiosa): 
   git push --force origin master
   Questo comando sovrascrive la cronologia remota con quella locale, potenzialmente cancellando il lavoro di altri. Deve essere utilizzato solo in scenari controllati (es. riscrittura della cronologia prima della pubblicazione ufficiale).

FIG 6 - git push origin main

Ispezione di un Repository Remoto (show)

Per gestire in maniera efficace le interazioni con repository remoti, Git mette a disposizione il comando:

git remote show <nome-remoto>

Questo strumento consente di ottenere una panoramica dettagliata sulle configurazioni associate a un determinato remote, come ad esempio l’URL di fetch e push, i branch tracciati e le impostazioni di sincronizzazione.

Utilizzo di base

Ad esempio, per ispezionare il remote predefinito origin:

git remote show origin

FIG 7 - git remote show origin

L’output restituisce informazioni essenziali, tra cui:

• Fetch/Push URL. Gli indirizzi utilizzati per scaricare (fetch) o pubblicare (push) dati.
• HEAD branch. Il branch predefinito del remote (spesso master o main).
• Remote branches. I branch remoti tracciati dal repository locale.
• Branch locali configurati per pull/push. Le associazioni automatiche di sincronizzazione.

Output avanzato in scenari complessi

In progetti di grandi dimensioni o con più branch remoti, l’output può essere molto più articolato.

FIG 8 - git remote show origin

In questo caso, emergono ulteriori informazioni:

• Branch nuovi (new)
  individuati sul server, ma non ancora scaricati localmente. Verranno sincronizzati al prossimo fetch.
• Branch obsoleti (stale)
  presenti localmente ma rimossi dal server. Git suggerisce di eliminarli con:
  git remote prune origin
• Associazioni multiple
  un branch locale può essere configurato per sincronizzarsi automaticamente con un branch remoto specifico.

Casi d’uso pratici

• Verifica rapida della configurazione remota prima di eseguire git pull o git push.
• Identificazione di branch obsoleti per mantenere un repository locale pulito.
• Controllo dei permessi e degli URL (utile quando si lavora con remoti accessibili sia via HTTPS che SSH).
• Diagnosi di problemi di sincronizzazione, ad esempio quando un branch non è correttamente tracciato.

Rinomina ed Eliminazione dei Repository Remoti (rename, remove)

La gestione dei repository remoti in Git non si limita alla loro configurazione iniziale: in determinati scenari può essere necessario rinominare un remote per una migliore leggibilità, oppure rimuoverlo se non più utilizzato. Git mette a disposizione comandi specifici per entrambe le operazioni.

1. Rinomina di un Remote

Per modificare il nome abbreviato (shortname) di un remote si utilizza:

git remote rename <vecchio-nome> <nuovo-nome>

Esempio

Se si desidera rinominare un remote chiamato pd24 in pippo:

git remote rename pd24 pippo
git remote

FIG 9 - git remote rename

L’operazione non si limita a rinominare il remote, ma aggiorna automaticamente anche tutti i riferimenti ai branch di tracking.

Ad esempio:

• Prima: pd24/main
• Dopo: pippo/main

Questo garantisce coerenza e riduce il rischio di errori manuali.

2. Rimozione di un Remote

Se un remote non è più necessario (ad esempio perché il server è stato spostato, un mirror è stato dismesso o un collaboratore non contribuisce più), è possibile eliminarlo con:

git remote remove <nome>

oppure, in alternativa:

git remote rm <nome>

Esempio

Per rimuovere il remote pippo:

git remote remove pippo
git remote

FIG 10 - git remote remove

Dopo l’eliminazione:

• Tutti i remote-tracking branch associati a quel remote vengono rimossi.
• Le configurazioni locali legate al remote (ad esempio impostazioni di fetch e push) vengono eliminate.

Tabella di Sintesi: Principali Operazioni sui Repository Remoti

Comando	Descrizione	Esempio
git remote -v	Elenca i remoti configurati con i rispettivi URL	git remote -v
git remote add <nome> <url>	Aggiunge un nuovo remoto	git remote add pd24  https://github.com/Pedestrian24/Hello.git
git fetch <remote>	Scarica i dati dal remoto senza integrarli	git fetch origin
git pull	Scarica e integra i dati dal remoto	git pull origin master
git push <remote> <branch>	Invia i commit locali al remoto	git push origin main
git remote show <remote>	Mostra dettagli di configurazione di un remoto	git remote show origin
git remote rename <old> <new>	Rinomina un remoto	git remote rename pd24 pippo
git remote remove <nome>	Rimuove un remoto e le relative configurazioni	git remote remove pippo

Best Practice

• Usare nomi coerenti: origin per il repository principale, upstream per il fork originale.
• Controllare sempre con git fetch prima di un git pull: riduce i conflitti e rende più prevedibile il flusso.
• Evitare git push --force salvo nei branch personali: può riscrivere la cronologia e creare problemi ai collaboratori.
• Pulire i branch remoti obsoleti con:
  git remote prune origin
• Preferire SSH a HTTPS per ambienti professionali: maggiore sicurezza e praticità nell’autenticazione.

Git: Annullare le operazioni

Durante lo sviluppo, può capitare di voler annullare una modifica o correggere un errore. Git offre diversi strumenti per gestire queste situazioni, ma è fondamentale utilizzarli con cautela: alcune operazioni di undo non sono reversibili e, se usate in modo improprio, possono comportare la perdita definitiva di lavoro.

Correggere l’ultimo commit con --amend

Uno degli scenari più comuni si verifica quando si effettua un commit troppo presto, dimenticando di includere un file o inserendo un messaggio di commit errato. In questi casi, Git consente di sostituire l’ultimo commit con uno nuovo tramite l’opzione --amend:

git commit --amend

Git prende il contenuto dell’area di staging (index) e lo utilizza per generare un nuovo commit.

Se non sono state aggiunte nuove modifiche dallo scorso commit, verrà riaperto semplicemente l’editor dei messaggi di commit, consentendo di modificarlo.

Esempio pratico

Supponiamo di aver eseguito il commit e di esserci resi conto di aver dimenticato di inserire le modifiche in un file che volevamo aggiungere a questo commit. Possiamo rimediare aggiungendo il file con git add e rieseguire il commit con git commit --amend:

git commit -m "Initial commit"
git add file_dimenticato
git commit --amend

Il repository avrà un solo commit, che include anche file_dimenticato. Il commit precedente viene sovrascritto e sparisce dalla cronologia.

Aspetti importanti da considerare

• Sostituzione, non modifica 
  - Amend non aggiorna un commit già esistente ma lo sostituisce con un nuovo commit dotato di un nuovo identificativo (SHA-1).
  - Di fatto, è come se il commit precedente non fosse mai esistito.
• Pulizia della cronologia
  - L’opzione --amend è utile per evitare commit ridondanti.
• Limitazione: solo commit locali
  - È fortemente sconsigliato eseguire git commit --amend su commit già pubblicati (pushed) in un repository remoto. Infatti, l’operazione riscrive la cronologia e, se accompagnata da un git push --force, può creare conflitti e problemi per gli altri collaboratori.

Tabella di sintesi: git commit --amend

Scenario	Comando	Risultato
Modificare solo il messaggio di commit	git commit --amend (senza nuovi file in staging)	Sovrascrive il messaggio dell’ultimo commit
Aggiungere file dimenticati	git add file + git commit --amend	Crea un nuovo commit che sostituisce il precedente includendo anche file
Commit già pushato sul remoto	git commit --amend + git push --force	Sconsigliato: riscrive la cronologia e può rompere il lavoro dei collaboratori

Rimuovere un File dall’Area di Staging

Durante il lavoro quotidiano con Git, può capitare di inserire per errore più file nell’area di staging (index) utilizzando un comando troppo generico, come ad esempio:

git add *

In questo caso, se l’obiettivo era committare i file separatamente, è necessario rimuovere uno o più file dallo staging (unstaging), riportandoli allo stato di semplici modifiche nella working directory.

A partire dalla versione 2.23.0, Git ha introdotto il comando git restore, concepito come alternativa più intuitiva e leggibile rispetto a git reset per alcune operazioni di annullamento (undo).

L’obiettivo di questo nuovo comando è semplificare la sintassi e ridurre i rischi legati a usi impropri di git reset, che in passato potevano facilmente portare alla perdita involontaria di dati.

la differenza principale tra git restore e git reset HEAD sta nel loro scopo e nell'ambito d'azione:

• git restore è un comando moderno e più sicuro, ideato per ripristinare i file nello stato in cui si trovavano in una versione precedente. Agisce sulla working directory (area di lavoro) o sulla staging area (area di "preparazione" prima del commit), ma non modifica la cronologia dei commit. È l'ideale per annullare modifiche locali, che non sono ancora state salvate nella cronologia.
• git reset HEAD è un comando più vecchio, versatile e potente, che agisce primariamente sulla cronologia dei commit. Sposta il puntatore HEAD a un commit precedente, e di conseguenza, può influenzare l'area di staging e l'area di lavoro a seconda dell'opzione utilizzata (--soft, --mixed, o --hard). È uno strumento più "distruttivo" e va usato con cautela, specialmente su branch condivisi, perché modifica la storia del repository.

Identificare i file in staging con git status

Il comando git status non solo mostra lo stato della working directory e dell’area di staging, ma fornisce anche indicazioni utili su come annullare operazioni indesiderate.

Esempio pratico:

Per individuare il file da rimuovere all'area di staging

git status

FIG 1 - git status

Come si può notare da FIG 1 , Git suggerisce direttamente il comando corretto per rimuovere un file dallo staging.

git restore --staged <file>

Nel nostro caso, per rimuovere il file main.cs dallo staging il comando sarà

git restore --staged main.cs

FIG 2 - git restore --staged

Lo stesso risultato lo si ottiene con 

git reset HEAD <file>

Il comando git reset è spesso considerato pericoloso, poiché con opzioni come --hard può portare alla perdita definitiva di modifiche locali. Tuttavia, in questo scenario, l’uso di git reset HEAD è sicuro perché non modifica i contenuti della working directory ma agisce esclusivamente sull’indice, rimuovendo il file dallo staging.

Tabella di sintesi: Comandi per gestire lo staging

Comando	Effetto
git add file	Aggiunge un file all’area di staging
git reset HEAD file	Rimuove il file dallo staging, mantenendo le modifiche nella working directory
git restore --staged file	Alternativa moderna a git reset HEAD file, con la stessa funzione
git reset --hard	Pericoloso: annulla anche le modifiche nella working directory

 

Annullare le modifiche a un File

Può capitare di accorgersi che le modifiche apportate a un file non sono più necessarie e che si desidera ripristinare il contenuto all’ultima versione tracciata da Git (ossia l’ultima presente nell’area di staging o nel commit più recente).

In questi casi, Git mette a disposizione due comandi storicamente equivalenti, ma con differenze importanti: git restore (introdotto in Git ≥ 2.23.0) e git checkout (metodo tradizionale).

Esempio pratico con git restore

Supponiamo di aver modificato il file main.cs. Eseguiamo il comando

git status

FIG 3 - git status

Per annullare le modifiche non salvate:

git restore main.cs

Dopo il comando, il file torna allo stato dell’ultimo commit o staging, eliminando definitivamente i cambiamenti locali.

FIG 4 - git restore

Esempio pratico con git checkout

git checkout -- main.cs

Anche in questo caso il file viene ripristinato, cancellando le modifiche locali.

FIG 5 - git checkout

Differenze tra git restore e git checkout

Caratteristica	git restore	git checkout
Disponibilità	Introdotto in Git ≥ 2.23.0	Presente in tutte le versioni di Git
Obiettivo	Progettato specificamente per annullare modifiche ai file (working directory e staging)	Comando multifunzione (cambio branch, ripristino file, navigazione)
Chiarezza sintattica	Più leggibile e autoesplicativo (restore indica chiaramente lo scopo)	Sintassi più generica e meno intuitiva
Rischio di confusione	Ridotto: il comando è dedicato solo al ripristino	Elevato: git checkout gestisce operazioni molto diverse tra loro
Best Practice	Consigliato nei workflow moderni per annullare modifiche locali	Ancora valido, ma da usare con cautela per evitare ambiguità

Attenzione

• Entrambi i comandi cancellano in modo irreversibile le modifiche locali non ancora salvate in un commit.
• Prima di utilizzarli, è opportuno chiedersi se le modifiche possano essere utili in futuro.
• In alternativa, si può ricorrere a git stash o a un nuovo branch, salvando temporaneamente i cambiamenti senza perderli.

È importante ricordare che soltanto ciò che è stato effettivamente sottoposto a commit può essere recuperato; le modifiche non salvate andranno invece perse in maniera definitiva.

In Git, i dati oggetto di commit risultano quasi sempre recuperabili, anche qualora appartengano a rami successivamente eliminati oppure siano stati sovrascritti tramite l’opzione --amend. Tutte le modifiche non ancora committate e andate perse non potranno, con ogni probabilità, essere ripristinate.

Best Practice

• Usare git restore nei progetti moderni: più chiaro e meno soggetto a errori.
• Evitare git checkout -- <file> se non strettamente necessario: mantiene la retrocompatibilità, ma può confondere.
• Ricorrere a git stash o ai branch per soluzioni temporanee: ideale se non si vuole perdere il lavoro fatto.

Git: Consultazione della Cronologia dei Commit

Dopo aver effettuato diversi commit, oppure quando si clona un repository con una cronologia già esistente, è fondamentale poter analizzare lo storico delle modifiche.

Lo strumento principale messo a disposizione da Git per questo scopo è il comando git log, che consente di ispezionare in dettaglio l’evoluzione di un progetto.

Il comando più semplice è:

git log

L’output predefinito elenca i commit in ordine cronologico inverso, mostrando per ciascun commit:

• l’hash SHA-1 univoco
• l’autore con email
• la data
• il messaggio di commit

FIG 1 - git log

Opzioni utili di git log

Git mette a disposizione un’ampia gamma di opzioni per adattare l’output alle proprie esigenze.

1. Mostrare le modifiche introdotte da ciascun commit

git log -p -2

• L’opzione -p (o --patch) visualizza le differenze introdotte.
• Il parametro -2 limita l’output agli ultimi due commit.
• Utile in fase di code review o per analizzare l’evoluzione del codice.

FIG 2 - git log -p -2

2. Visualizzare statistiche sintetiche

git log --stat

Mostra i file modificati, il numero di righe aggiunte/rimosse e un riepilogo finale.

FIG 3 - git log --stat

git log --shortstat

Questo comando fornisce un riassunto molto conciso per ogni commit. Mostra un'unica riga con il conteggio totale dei file modificati e il numero totale di righe aggiunte e cancellate. Non elenca i nomi specifici dei file.

3. Formattazione personalizzata

Consente di definire un formato personalizzato dell’output, utile per generare report o output leggibili da script.

git log --pretty=format:"%h - %an, %ar : %s"

Segnaposto principali

Segnaposto	Descrizione
%H	Hash completo del commit
%h	Hash abbreviato
%T	Hash dell'albero
%t	Hash dell'albero abbreviato
%P	Hash dei genitori
%p	Hash dei genitori abbreviati
%an	Nome autore
%ae	Email autore
%ad	Data autore (formato configurabile con --date=)
%ar	Data autore relativa (es. “2 weeks ago”)
%cn	Nome committer
%ce	Email committer
%cd	Data del committer
%cr	Data del committer, relativa
%s	Messaggio del commit

FIG 4 - git log --pretty=format

4. Output compatti

• git log --oneline
  commit in una sola riga (hash abbreviato + messaggio).
• git log --pretty=short|full|fuller
  diversi livelli di dettaglio.
• git log --abbrev-commit
  mostra solo le prime cifre dell’hash.

FIG 5 - git log --oneline

5. Rappresentazione grafica

Visualizza un grafico ASCII che illustra la struttura di branch e merge, molto utile in repository complessi.

git log --graph

FIG 6 - git log --graph

Opzioni per limitare l'output di git log

Oltre alle opzioni di formattazione, il comando git log supporta numerose opzioni di limitazione, che consentono di filtrare i commit mostrati.

Queste opzioni sono utili per concentrarsi su un intervallo temporale, un autore, un file specifico o persino su modifiche particolari al codice.

1. Limitazione numerica

Per visualizzare solo gli ultimi n commit:

git log -2

Mostra solo gli ultimi due commit.

FIG 7 - git log -2

2. Limitazione temporale

È possibile filtrare i commit in base a date assolute o relative:

git log --since=2.weeks

git log --since="2025-01-01" --until="2025-01-31"

--since / --after  

commit successivi a una certa data.

--until / --before 

commit precedenti a una certa data.

Esempi validi di date:

"2008-01-15" (formato ISO)

"2 years 1 day 3 minutes ago" (relativo)

3. Filtrare per autore o committer

git log --author="Alice"

git log --committer="Bob"

--author  
mostra commit scritti da un certo autore.

--committer
mostra commit applicati da uno specifico committer.

É possibile utilizzare più di una regola --author o --grep contemporaneamente.

Con l’opzione --all-match, Git mostrerà solo i commit che soddisfano tutti i criteri.

4. Ricerca nei messaggi di commit

git log --grep="bugfix"

Mostra i commit che hanno "bugfix" nel messaggio di commit.

Può essere combinato con --author e --since per ricerche più precise.

5. Pickaxe: cercare modifiche nel codice

git log -S function_name

L’opzione -S (detta pickaxe) trova i commit in cui cambia il numero di occorrenze di una stringa (es. aggiunta o rimozione di una funzione).

Ottimo per capire quando e perché è stata introdotta o rimossa una porzione di codice.

6. Limitazione per file o directory

git log -- path/to/file

Mostra solo i commit che hanno modificato un file o una directory specifica.

Per separare chiaramente le opzioni dal percorso si usa --:

git log --since="2025-01-01" -- path/to/file

7. Evitare i merge commit

In repository con workflow basati su merge, la cronologia può risultare affollata.

Per nascondere i merge commit non informativi:

git log --no-merges

Tabelle riepilogative delle opzioni comuni

Opzione	Descrizione
-p o --patch	Mostra le differenze introdotte da ciascun commit
--stat	Riepilogo file modificati e righe aggiunte/rimosse
--shortstat	Solo il riepilogo numerico (senza elenco file)
--name-only	Elenco dei file modificati
--name-status	Elenco file + stato (A=Added, M=Modified, D=Deleted)
--abbrev-commit	Hash abbreviati
--relative-date	Date in formato relativo (“2 days ago”)
--graph	Grafico ASCII della cronologia
--pretty	Formati alternativi (oneline, short, full, fuller, format)
--oneline	Alias di --pretty=oneline --abbrev-commit. Mostra ogni commit su una singola riga

Opzioni di filtro

Opzione	Descrizione
-n <numero>	Limita il numero di commit visualizzati all'ultimo <numero> specificato
--author="<pattern>"	Filtra i commit in base all'autore. Accetta anche espressioni regolari.
--committer="<pattern>"	Filtra i commit in base al committer.
--grep="<pattern>"	Filtra i commit in base a un pattern nel messaggio del commit.
--since="<data>"	Visualizza i commit a partire da una data specificata("2 weeks ago", "2023-01-01", "yesterday").
--until="<data>"	Visualizza i commit fino a una data specificata.
--after="<data>"	Alias di --since
--before="<data>"	Alias di --until
<file-o-cartella>	Mostra solo i commit che hanno modificato un file o una cartella specifica
--merges	Mostra solo i commit di merge.
--no-merges	Esclude i commit di merge dalla visualizzazione.

Opzioni di navigazione

Opzione	Descrizione
--reverse	Limita il numero di commit visualizzati all'ultimo <numero> specificato
<start>..<end>	Filtra i commit in base all'autore. Accetta anche espressioni regolari.
-S"<stringa>" o --all-match-S"<stringa>"	Mostra i commit che hanno introdotto o rimosso una riga contenente una stringa specifica. Utile per il debugging.
-G"<regex>"	Simile a -S, ma usa un'espressione regolare per cercare le modifiche nel contenuto dei file

Differenza tra autore e committer

• Autore (Author): chi ha scritto originariamente la modifica.
• Committer: chi ha applicato la modifica al repository (può coincidere con l’autore o essere un maintainer che ha accettato una patch).

Questo permette di riconoscere sia chi ha prodotto il codice sia chi ne ha garantito l’integrazione

Esempio avanzato

Visualizzare i commit:

• scritti da Giovanni Lubrano Lavadera,
  
• nel mese di novembre 2024,
• che non siano merge commit,
• relativi alla directory test/

git log --pretty="%h - %s" \
  --author="Giovanni Lubrano Lavadera" \
  --since="2024-11-01" \
  --before="2024-12-01" \
  --no-merges -- test/