06. Interrogare lo stato e la history

6.1 git status

Mostra lo stato della working directory e della staging area, con suggerimenti sui comandi da usare per spostare le modifiche tra i vari stati:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   02-save-changes.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   03-query-status.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        preview.html

Lo stesso output segnala anche l’avanzamento di operazioni avanzate come rebase o merge, suggerendo il comando per proseguire o tornare indietro.

6.2 git tag

I tag sono riferimenti a specifici commit, usati tipicamente per contrassegnare release/versioni. A differenza dei branch, un tag non si sposta con i nuovi commit.

git tag <NAME>               # tag "lightweight": semplice segnalibro
git tag -a <NAME> -m "msg"   # tag "annotated": con autore, data e messaggio
git tag                      # elenca i tag
git tag -l "*beta*"          # filtra con wildcard
git tag -a v1.2.0 <commit>   # tagga un commit specifico
git tag -d <NAME>            # elimina un tag
git tag -f v1 -m "msg"       # sposta un tag su un altro commit

• I tag lightweight sono adatti come segnalibri locali di commit importanti, non per rilasci pubblici.
• I tag annotated salvano metadati e messaggio: la scelta giusta per le release.
• Un commit può avere più tag, e con -f si può spostare un tag esistente su un commit nuovo.

Esempio: convenzione con un tag per la versione esatta (v1.0.0) e un tag generico v1 che punta sempre all’ultimo rilascio della major 1. Al rilascio della 1.1.0 si crea il nuovo tag e si forza l’aggiornamento di v1:

$ git tag
v1
v1.0.0

$ git add package.json
$ git commit -m "release version 1.1.0"
$ git tag v1.1.0 -m "tagging version 1.1.0"
$ git tag -f v1 -m "moving tag v1 to latest release"

Queste convenzioni sono scelte di progetto, non regole di Git.

Come ogni riferimento, i tag si possono usare in altri comandi: git checkout v1.3.0 (estrae il commit taggato), git diff v1.1.1-beta..v1.1.1-beta2 (confronta due tag), ecc.

6.3 git blame

Risponde alla domanda “chi ha modificato questa riga?”. Per ogni riga del file mostra: id del commit, autore, data, numero di riga e contenuto.

$ git blame gradle.properties
2a0629fa2 (John Doe  2021-03-04 19:55:36 +0100 1) kotlin.code.style=official
f9fba3a0e (Jane Foo  2021-05-27 14:13:45 +0200 2) # for local development...
f9fba3a0e (Jane Foo  2021-05-27 14:13:45 +0200 3) org.gradle.caching=true

Opzioni: -w (ignora variazioni di spazi), -M (ignora righe spostate nello stesso file), -C (rileva righe spostate/copiate da altri file).

⚠️ git blame mostra solo chi ha toccato per ultimo una riga, non chi ha introdotto un eventuale bug (la scelta tra blame e log dipende da cosa si sta cercando).

6.4 git log

Visualizza, filtra e cerca nella cronologia dei commit:

git log                                # cronologia completa (spazio scorre, q esce)
git log -n <LIMITE>                    # solo gli ultimi N commit
git log --oneline                      # un commit per riga
git log --stat                         # con file modificati e conteggio righe
git log -p                             # con le differenze effettive
git log --author="<pattern>"           # filtra per autore
git log --grep="<pattern>"             # filtra per testo nel messaggio
git log <file>                         # solo i commit che toccano quel file
git log <inizio>..<fine>               # solo i commit tra due riferimenti
git log --graph --decorate --oneline   # vista grafica con branch e tag

Esempio combinato — i propri commit degli ultimi giorni:

git log --since '3 days ago' --oneline --author "$(git config user.email)"