Git Diff spiegato: guida completa con esempi

Git diff è la tua finestra sulle modifiche che avvengono nel tuo repository di codice. In sostanza, è un comando che ti mostra le differenze tra i vari stati dei tuoi file — che si tratti di confrontare il tuo lavoro attuale con ciò che hai già messo in stage o di confrontare le modifiche tra branch e commit. Pensalo come il modo in cui Git risponde alla domanda: “Che cosa è cambiato?”. Quando esegui git diff, Git analizza il contenuto dei file riga per riga, identifica ciò che è stato aggiunto, rimosso o modificato e presenta queste informazioni in un formato standardizzato che evidenzia esattamente cosa è cambiato e dove.

Git diff aiuta gli sviluppatori a garantire la qualità del codice offrendo una vista chiara delle modifiche prima che vengano effettuati i commit. Qui vedremo come usare in modo efficace questo comando essenziale, dai confronti di base alle tecniche avanzate che miglioreranno il tuo flusso di lavoro di sviluppo e la collaborazione nel team.

Prerequisiti

Per seguire questo tutorial, dovresti avere familiarità con questi concetti di Git:

• Workflow di base di Git (init, add, commit)
• Repository Git e loro struttura
• Branch e come funzionano
• Commit e cronologia dei commit
• Area di staging (index)

Se vuoi ripassare questi concetti, queste risorse ti saranno utili:

• Git Cheat Sheet — Riferimento rapido per i comandi Git più comuni
• Corso Introduction to Git — Per chi inizia e vuole imparare le basi di Git
• GitHub and Git Tutorial for Beginners — Introduzione pratica a Git e GitHub
• Corso Intermediate Git — Per chi è pronto ad avanzare con Git

Ti servirà avere Git installato sul tuo sistema per seguire gli esempi. Tutti i comandi possono essere eseguiti in un terminale o prompt dei comandi.

Perché Git Diff è essenziale per gli sviluppatori

Ogni sviluppatore ha bisogno di sapere cosa è cambiato nel proprio codice, che lavori da solo o in un team di centinaia di persone. Senza git diff, dovresti indovinare quali righe hai modificato, rendendo il debugging e la collaborazione quasi impossibili.

Git diff è fondamentale per la gestione delle modifiche e costituisce la base per costruire software di qualità tramite processi di revisione efficaci. Quando esamini le modifiche, git diff fornisce il contesto necessario per capire non solo cosa è cambiato, ma anche perché quelle modifiche sono importanti. 

Questa visibilità diretta nell’evoluzione del codice aiuta i team a mantenere standard elevati e a prevenire che i bug arrivino in produzione.

Man mano che i progetti crescono in complessità, git diff diventa davvero indispensabile per diversi motivi chiave:

• Verifica delle modifiche: Conferma esattamente cosa stai per fare commit, evitando di includere per errore codice di debug o cambiamenti non correlati
• Trasferimento di conoscenza: Capisci cosa hanno fatto i compagni di squadra senza dover leggere interi file
• Risoluzione dei conflitti: Identifica esattamente dove e come i cambiamenti entrano in conflitto durante i merge
• Analisi storica: Traccia quando sono state introdotte specifiche modifiche per trovare bug o capire l’evoluzione delle funzionalità
• Code review mirate: Concentrati sulle parti di codice effettivamente cambiate, risparmiando tempo e migliorando la qualità delle revisioni

Per usare efficacemente git diff, è necessario comprendere l’architettura sottostante che abilita questi confronti — il modello a “Tre alberi” di Git.

L’architettura a Tre Alberi di Git

Per capire git diff, devi prima afferrare la fondamentale architettura a “tre alberi” di Git. Nonostante il nome, non sono alberi reali nel file system, ma tre stati distinti in cui esiste il tuo codice. 

Pensa a questi stati come a tre diverse versioni del tuo progetto che Git tiene traccia contemporaneamente: la Working Directory (i tuoi file reali), la Staging Area (o index, dove le modifiche vengono preparate per il commit) e il Repository (la cronologia dei commit del tuo progetto conservata nella directory .git).

Fonte: Hashnode

La Working Directory contiene i file che stai modificando attivamente — qui scrivi il codice, fai cambiamenti e testi il tuo lavoro. La Staging Area è una zona di preparazione in cui selezioni quali modifiche includere nel prossimo commit. Puoi pensarla come un molo di carico dove i pacchi (le tue modifiche) vengono organizzati prima della spedizione. 

Infine, il Repository conserva la cronologia completa del tuo progetto come una serie di commit, snapshot del tuo codice in momenti specifici, collegati tra loro a formare una catena storica.

Git diff opera confrontando questi tre stati in varie combinazioni. Quando esegui git diff senza argomenti, confronta la tua Working Directory con la Staging Area, mostrando le modifiche che hai fatto ma non ancora messe in stage. 

Usare git diff --staged confronta la Staging Area con l’ultimo commit, mostrando cosa verrà incluso nel prossimo commit. 

E git diff HEAD confronta direttamente la Working Directory con l’ultimo commit, mostrando tutte le modifiche non confermate indipendentemente dallo stato di staging.

Questi punti di confronto costituiscono la base di tutte le operazioni di diff in Git:

• Working Directory ↔ Staging Area: Quali modifiche ho fatto ma non ancora messe in stage? (git diff)
• Staging Area ↔ Repository: Quali modifiche ho messo in stage che saranno confermate nel prossimo commit? (git diff --staged)
• Working Directory ↔ Repository: Qual è la differenza totale tra i miei file di lavoro e l’ultimo commit? (git diff HEAD)
• Tra commit: Come è evoluto il codice tra punti specifici della storia? (git diff commit1-hash commit2-hash)

Capire questa architettura ti dà il modello mentale necessario per usare efficacemente git diff e individuare esattamente cosa è cambiato, dove e quando nella tua codebase.

Con questa comprensione architetturale, possiamo ora esplorare come usare in pratica i comandi git diff per ottenere informazioni sull’evoluzione del tuo codice attraverso questi tre stati.

Uso di base di Git Diff

Creiamo un progetto di analisi dati di esempio per vedere git diff in azione. Imposteremo un piccolo repository con script Python, dati CSV e file di testo che potremo modificare lungo tutto il tutorial.

# Create and initialize our project
mkdir data-analysis-project
cd data-analysis-project
git init

# Create initial files
echo "# Data Analysis Project\nA sample project to demonstrate git diff functionality." > README.md
echo "import pandas as pd\n\ndef load_data(filename):\n return pd.read_csv(filename)\n\ndef analyze_data(data):\n return data.describe()" > analysis.py
echo "id,name,value\n1,alpha,10\n2,beta,20\n3,gamma,30" > data.csv
echo "DEBUG=False\nDATABASE_PATH=./data/" > config.txt
echo "def normalize_data(data):\n return (data - data.min()) / (data.max() - data.min())" > utils.py

# Make our first commit
git add .
git commit -m "Initial commit with basic project structure"

# Check the directory structure
> tree

.
├── README.md
├── analysis.py
├── config.txt
├── data.csv
└── utils.py

Il nostro progetto ora ha cinque file sotto controllo di versione, dandoci una base per dimostrare vari scenari di diff. Proseguendo, modificheremo questi file per mostrare come git diff rivela i cambiamenti in diversi contesti.

Capire i risultati di git diff

Quando esegui un comando git diff, l’output segue un formato standard pensato per indicare chiaramente cosa è cambiato. Modifichiamo il file analysis.py per vedere un diff in azione:

# Update analysis.py with a new function
echo "import pandas as pd\n\ndef load_data(filename):\n return pd.read_csv(filename)\n\ndef analyze_data(data):\n return data.describe()\n\ndef visualize_data(data):\n return data.plot(kind='bar')" > analysis.py

Ora esaminiamo il git diff risultante:

git diff

Vedrai un output simile a questo:

Nota: per uscire dall’output di git diff, premi “q” nel terminale.

Scomponiamo questo output:

1. L’header (diff --git a/analysis.py b/analysis.py) mostra quale file viene confrontato, cioè analysis.py
2. I metadati del file (index db0e049..a7a7ab0 100644) mostrano gli identificatori interni di Git per le versioni precedente e successiva
3. I marcatori di file (--- a/analysis.py and +++ b/analysis.py) indicano i file "prima" e "dopo"
4. L’header dell’hunk (@@ -5,3 +5,6 @@) mostra quali righe sono state interessate. Questa notazione può essere interpretata così:

• -5,3 significa che, a partire dalla riga 5 del file originale, nel diff vengono mostrate 3 righe
• +5,6 significa che, a partire dalla riga 5 del file modificato, nel diff vengono mostrate 6 righe
• La differenza tra questi numeri indica che sono state aggiunte 3 righe

5. Le modifiche al contenuto con righe che iniziano con + indicano le aggiunte

Nei file più grandi, git diff raggruppa le modifiche in “hunk” — sezioni del file che contengono cambiamenti. Ogni hunk ha il proprio header con i numeri di riga per aiutarti a localizzare le modifiche nel file.

Confrontare working directory e staging area

Eseguire git diff senza argomenti confronta la tua Working Directory (stato attuale dei file) con la Staging Area (modifiche pronte per il commit). È utile per rivedere quello che hai cambiato ma non hai ancora preparato per il prossimo commit.

Modifichiamo più file per dimostrare:

# Update README.md
echo "# Data Analysis Project\nA sample project to demonstrate git diff functionality.\n\n## Installation\nRun \pip install -r requirements.txt" > README.md

# Update data.csv
echo "id,name,value\n1,alpha,10\n2,beta,20\n3,gamma,30\n4,delta,40" > data.csv

Ora mettiamo in stage solo le modifiche a README.md:

git add README.md

Eseguendo git diff ora verranno mostrate solo le modifiche non in stage a data.csv e al file analysis.py sopra:

Questo ti aiuta a concentrarti su ciò che non hai ancora messo in stage. Se vuoi vedere quello che hai già messo in stage:

git diff --staged # or git diff --cached (they're synonyms)

Questo mostrerà le modifiche a README.md che sono in stage e pronte per il commit. Questo flusso di lavoro è cruciale per costruire commit puliti e logici. Puoi mettere in stage porzioni del tuo lavoro che hanno senso insieme, rivedere il diff in stage per verificare che sia un’unità coerente di cambiamento e poi fare commit.

Confrontare la staging area e l’ultimo commit

Il comando git diff --staged confronta la tua Staging Area con l’ultimo commit. Ti mostra esattamente cosa sarà incluso nel prossimo commit se esegui git commit ora.

Mettiamo in stage le modifiche a data.csv ed esaminiamo cosa è in stage:

git add data.csv
git diff --staged

L’output mostrerà ora le modifiche sia a README.md che a data.csv, poiché entrambe sono state messe in stage. Questo passaggio di revisione è fondamentale prima del commit — funziona come ultima linea di difesa contro il commit di modifiche involontarie.

Un workflow tipico potrebbe essere:

1. Apporta modifiche a più file
2. Esegui git diff per rivedere tutte le modifiche
3. Usa git add <file> in modo selettivo per mettere in stage gruppi logici di modifiche
4. Esegui git diff --staged per verificare cosa stai per confermare
5. Conferma le modifiche in stage con git commit -m "Your message"
6. Ripeti per altri raggruppamenti logici di modifiche

Questo approccio metodico aiuta a mantenere una cronologia di commit pulita e significativa, che rende più facile capire come è evoluto il progetto e individuare dove potrebbero essere stati introdotti dei problemi. Con l’esperienza, questi comandi di diff diventeranno naturali, i tuoi compagni costanti nel processo di sviluppo.

Facciamo i commit prima di passare alla fase successiva:

# data.csv and README.md are to be committed
git commit -m "Modify data.csv and README.md files"

# Stage and commit analysis.py
git add analysis.py
git diff --staged  # Review the changes one more time
git commit -m "Add a new function to analysis.py"

Tecniche intermedie di Git Diff

Ora che abbiamo capito le basi di git diff, esploriamo tecniche più potenti che miglioreranno la tua capacità di tracciare e analizzare le modifiche nei tuoi progetti. Continueremo a lavorare con il nostro progetto di analisi dati per dimostrare questi concetti intermedi.

Confrontare tra diversi riferimenti

Git è costruito attorno al concetto di riferimenti — puntatori a stati specifici del tuo codice. Questi riferimenti includono branch, commit e tag. Il comando git diff può confrontare qualsiasi coppia di questi riferimenti per mostrare cosa è cambiato tra di essi.

Creiamo un nuovo branch per sviluppare una funzionalità e apportiamo alcune modifiche:

# Create and switch to a new branch
git checkout -b feature/advanced-analytics

# Modify the analysis.py file with a new function
echo "import pandas as pd
import numpy as np

def load_data(filename):
   return pd.read_csv(filename)

def analyze_data(data):
   return data.describe()

def visualize_data(data):
   return data.plot(kind='bar')

def perform_advanced_analysis(data):
   """Performs advanced statistical analysis on the dataset"""
   results = {}
   results['correlation'] = data.corr()
   results['skew'] = data.skew()
   return results" > analysis.py

# Commit the changes
git add analysis.py
git commit -m "Add advanced analysis function"

Ora possiamo confrontare il nostro branch della feature con il branch main:

git diff main feature/advanced-analytics

Questo comando mostra tutte le differenze tra i due branch — ogni file che è stato modificato, aggiunto o eliminato. Vedrai le modifiche che abbiamo fatto a analysis.py, inclusi i nuovi import e la funzione (premi invio più volte perché il diff completo può essere troncato nel terminale).

Per confrontare con un commit specifico, puoi usare l’hash del commit:

git log --oneline  # Find the commit hash you want to compare with

git diff 7b3105e  # Replace 7b3105e with the actual commit hash you want to compare

Questa capacità di confronto diventa inestimabile quando:

• Ti prepari alle code review vedendo tutte le modifiche in un branch di feature
• Controlli quali modifiche introdurrebbe il branch di un collega prima del merge
• Capisci come la tua codebase è evoluta tra rilasci o versioni

Confrontare file specifici

Quando lavori con repository grandi, spesso vuoi concentrarti sulle modifiche a file o directory specifici invece di vedere tutte le differenze. Git diff lo rende semplice permettendoti di specificare i percorsi.

Facciamo modifiche a più file:

# Update config.txt
echo "DEBUG=True
DATABASE_PATH=./data/
LOG_LEVEL=INFO" > config.txt

# Update utils.py
echo "def normalize_data(data):
   return (data - data.min()) / (data.max() - data.min())

def clean_data(data):
   return data.dropna()" > utils.py

Per vedere le modifiche solo al file di configurazione:

git diff config.txt

Oppure per confrontare un file specifico tra branch:

# Compare analysis.py file between main and feature/advanced-analytics branches
git diff main feature/advanced-analytics -- analysis.py

Le -- nel comando sopra aiutano Git a distinguere tra riferimenti e percorsi di file. È particolarmente utile quando:

• Lavori in repository con molti file ma ti concentri su componenti specifici (cosa che spesso accade)
• Controlli come è cambiata la configurazione tra branch
• Rivedi solo i file più critici in un insieme ampio di modifiche

Opzioni di diff contestuali

Git diff offre diverse opzioni per regolare come vengono visualizzate le differenze, rendendo più semplice concentrarsi sui cambiamenti significativi.

Ad esempio, quando si ha a che fare con modifiche di formattazione del codice, le differenze di spazi bianchi possono offuscare cambiamenti semantici importanti. Dimostriamo con una modifica di formattazione:

# Make a whitespace change to analysis.py
sed -i '' 's/    return/  return/g' analysis.py  # Reduce indentation

Ora, confrontando con git diff standard si vedono le modifiche agli spazi bianchi (nota come le istruzioni return siano disallineate):

git diff analysis.py

# OUT:
--- a/analysis.py
+++ b/analysis.py
@@ -2,17 +2,17 @@ import pandas as pd
import numpy as np

def load_data(filename):
-    return pd.read_csv(filename)
+  return pd.read_csv(filename)

def analyze_data(data):
-    return data.describe()
+  return data.describe()

def visualize_data(data):
-    return data.plot(kind='bar')
+  return data.plot(kind='bar')

def perform_advanced_analysis(data):
    Performs advanced statistical analysis on the dataset
    results = {}
    results['correlation'] = data.corr()
    results['skew'] = data.skew()
-    return results
+  return results

Ma possiamo ignorare le modifiche agli spazi bianchi (questo non mostrerà cambiamenti dato che abbiamo solo rimosso spazi):

git diff -w analysis.py  # or --ignore-all-space

Un’altra opzione utile è controllare le righe di contesto — le righe invariate mostrate attorno alle modifiche:

git diff -U1 analysis.py  # Show only 1 line of context (default is 3)
git diff -U5 analysis.py  # Show 5 lines of context

Queste opzioni contestuali sono particolarmente preziose quando:

• Rivedi codice passato per un formattatore automatico
• Ti concentri sui cambiamenti funzionali piuttosto che sullo stile
• Hai bisogno di più contesto per capire una modifica specifica
• Lavori con file grandi in cui il contesto predefinito genererebbe troppo output

Padroneggiando queste tecniche intermedie, avrai un controllo molto più fine su come rivedere e comprendere le modifiche nella tua codebase, rendendo più efficiente il tuo workflow di sviluppo e più efficaci le code review.

Facciamo il commit delle ultime modifiche prima di passare alle applicazioni avanzate di git diff:

git add .
git commit -m "Modify analysis.py, config.txt, and utils.py"

Applicazioni avanzate di Git Diff

Sulla base della comprensione delle tecniche intermedie di git diff, esploriamo alcune applicazioni avanzate che porteranno le tue abilità Git al livello successivo. Queste tecniche sono particolarmente utili quando lavori su codebase complesse o collabori con team più grandi.

Usare strumenti di diff esterni

Sebbene il diff integrato in Git sia potente, a volte uno strumento visuale offre maggiore chiarezza, specialmente per modifiche complesse. Git ti permette di configurare strumenti esterni per migliorare l’esperienza di diff.

Configuriamo un popolare strumento di diff visuale. Useremo VSCode come esempio, ma una configurazione simile funziona per strumenti come Beyond Compare, Meld o KDiff3:

# Configure Git to use VSCode as the diff tool (project-specific)
git config diff.tool vscode
git config difftool.vscode.cmd "code --wait --diff \$LOCAL \$REMOTE"

# To use other popular tools, you could use:
# For Beyond Compare (project-specific):
git config diff.tool bc3
git config difftool.bc3.path "/path/to/beyond/compare"

# Installation commands:
# For Beyond Compare:
# On macOS: brew install --cask beyond-compare
# On Ubuntu: sudo apt-get install beyond-compare
# On Windows: Download from https://www.scootersoftware.com/download.php

# Note: To apply these settings globally instead of just the current project,
# add the --global flag to each command, for example:
# git config --global diff.tool vscode

Ora, invece di usare git diff, puoi usare:

git difftool main feature/advanced-analytics

Questo aprirà lo strumento di diff visuale configurato per mostrare le modifiche. Ecco come appare Beyond Compare:

Gli strumenti di diff visuale offrono diversi vantaggi:

1. Confronto affiancato che rende più semplice vedere il contesto
2. Evidenziazione della sintassi in linea con le preferenze del tuo editor
3. Navigazione avanzata tra le modifiche
4. Possibilità di modificare i file direttamente durante la revisione delle differenze

Quando si rivedono grandi cambiamenti o file con strutture complesse (come JSON o XML annidati), gli strumenti visuali possono migliorare notevolmente comprensione ed efficienza.

Comandi di diff specializzati

Git offre comandi di diff specializzati che ti danno un controllo più granulare per casi d’uso specifici. Esploriamo alcuni di questi potenti comandi:

git diff-tree esamina le differenze tra oggetti tree (directory):

# Get the hash of the last two commits
LAST_COMMIT=$(git rev-parse HEAD)
PREV_COMMIT=$(git rev-parse HEAD~1)

# Show changes in the last commit
git diff-tree --patch $PREV_COMMIT $LAST_COMMIT

git diff-index confronta la working tree con l’index (staging area) o con un tree:

# Compare working directory with the index
git diff-index --patch HEAD

git diff-index è particolarmente utile per scripting e automazione. Ti permette di controllare in modo programmatico quali modifiche verrebbero incluse nel prossimo commit, risultando prezioso per pre-commit hook e script di validazione.

Ad esempio, potresti usarlo in una pipeline CI/CD per verificare che determinati file non siano stati modificati o per assicurarti che le modifiche alla configurazione seguano schemi specifici prima di consentire i commit.

git diff-files mostra le modifiche tra i file nella working directory e l’index:

# Check differences for specific files
git diff-files --patch config.txt

Questi comandi specializzati sono particolarmente utili per:

• Creare workflow e script Git personalizzati
• Fare debug di problemi interni a Git
• Eseguire analisi mirate dello stato del repository
• Costruire strumenti di automazione che interagiscono con Git

Analizzare la storia del codice

Una delle applicazioni più potenti di git diff è analizzare come il codice è evoluto nel tempo, cruciale per il debugging o per capire lo sviluppo di una funzionalità.

Esaminiamo un commit specifico usando la notazione speciale ^!:

# Get the hash of our advanced analytics commit
ANALYTICS_COMMIT=$(git log --oneline | grep "advanced analysis" | cut -d ' ' -f 1)

# Show only changes introduced in that specific commit
git diff $ANALYTICS_COMMIT^!

La sintassi ^! è una scorciatoia per confrontare un commit con il suo genitore, mostrando esattamente cosa è cambiato solo in quel commit.

Per tracciare come un file specifico è evoluto nel tempo:

# Analyze how analysis.py changed over the last 3 commits
git log -p -3 analysis.py

Quando cerchi un bug, puoi usare git diff con git bisect:

# Add a bug to simulate a regression
echo "import pandas as pd
import numpy as np

def load_data(filename):
   # Bug: accidentally returning None instead of the data
   pd.read_csv(filename)
   return None

def analyze_data(data):
   return data.describe()

def visualize_data(data):
   return data.plot(kind='bar')

def perform_advanced_analysis(data):
   results = {}
   results['correlation'] = data.corr()
   results['skew'] = data.skew()
   return results" > analysis.py

git add analysis.py
git commit -m "Update analysis.py with a hidden bug"

# Now use git bisect to find when the bug was introduced
git bisect start
git bisect bad  # Mark current commit as containing the bug
git bisect good main  # Mark the main branch as working correctly

# Git will check out commits for you to test
# Once found, you can examine the exact change that introduced the bug
git diff HEAD^!

Git bisect è un potente strumento di debugging che esegue una ricerca binaria nella tua cronologia dei commit per trovare quale commit ha introdotto un bug. Combinato con git diff, crea un workflow efficiente:

1. Avvia il processo di bisect con git bisect start

2. Segna il commit corrente come difettoso (che contiene il bug) con git bisect bad

3. Segna un commit noto come buono (in cui il bug non esiste) con git bisect good <commit-hash>

4. Git effettua automaticamente il checkout di un commit a metà della tua storia da testare.

5. Dopo aver testato il commit corrente, comunica a Git il risultato:

• Se il bug esiste in questo commit: git bisect bad
• Se il bug non esiste in questo commit: git bisect good

6. Git continuerà a effettuare il checkout di commit diversi in base al tuo feedback (dopo ogni comando git bisect bad/good), restringendo la ricerca ogni volta. Ripeti il test e la marcatura fino a quando Git identifica il primo commit difettoso.

7. Una volta trovato il commit problematico, Git mostrerà un messaggio che indica quale commit ha introdotto il bug.

8. Esamina esattamente cosa è cambiato nel commit identificato con: git diff HEAD^!

9. Questo comando ti mostra con precisione quale codice è stato modificato nel commit che ha introdotto il bug, permettendoti di concentrare il debugging su quei cambiamenti specifici.

10. Esci dal bisect in qualsiasi momento con: git bisect reset Questo ti riporterà al branch su cui eri prima di iniziare il processo.

11. Puoi anche automatizzare il processo di bisect con: git bisect run <test-script> dove è un comando che restituisce 0 per i commit buoni e un valore diverso da zero per quelli difettosi.

Questo workflow riduce drasticamente i tempi di debugging, specialmente in codebase grandi con molti commit tra stati funzionanti e rotti.

Queste tecniche di analisi della storia sono inestimabili per:

• Trovare quando e perché è stato introdotto un bug
• Capire l’evoluzione di una funzionalità o componente
• Verificare le modifiche per revisioni di sicurezza
• Documentare il processo decisionale dietro i cambiamenti al codice

Padroneggiando queste applicazioni avanzate di git diff, potrai navigare nella storia del tuo progetto con precisione, fare debug più efficacemente e ottenere approfondimenti più profondi sull’evoluzione della tua codebase.

Riferimento ai comandi Git Diff

Git diff offre un’ampia gamma di opzioni per personalizzare output e comportamento in situazioni specifiche. Ecco un riferimento completo dei parametri più usati per migliorare la tua analisi differenziale:

Opzioni di confronto di base

• git diff - Confronta la working directory con la staging area
• git diff --staged (o --cached) - Confronta la staging area con l’ultimo commit
• git diff HEAD - Confronta la working directory con l’ultimo commit
• git diff <commit> - Confronta la working directory con un commit specifico
• git diff <commit1> <commit2> - Confronta due commit specifici
• git diff <branch1> <branch2> - Confronta due branch

Limitazione per percorso

• git diff -- <path> - Limita il confronto a uno specifico file o directory
• git diff --stat - Mostra un riepilogo delle modifiche (file modificati, inserimenti, eliminazioni), un’opzione molto utile per diff di grandi dimensioni
• git diff --name-only - Mostra solo i nomi dei file modificati
• git diff --name-status - Mostra i nomi e lo stato (aggiunto, modificato, eliminato) dei file cambiati

Controllo della visualizzazione

• git diff -w (o --ignore-all-space) - Ignora le modifiche agli spazi bianchi
• git diff --ignore-space-change - Ignora le modifiche nella quantità di spazi bianchi
• git diff --color-words - Mostra differenze a livello di parola con colori
• git diff --word-diff - Mostra differenze a livello di parola in un formato diverso
• git diff -U<n> - Mostra n righe di contesto (il valore predefinito è 3)
• git diff --no-prefix - Non mostra i prefissi a/ e b/ nell’output del diff

Filtraggio dei contenuti

• git diff --binary - Mostra le modifiche ai file binari
• git diff -S<string> - Cerca modifiche che aggiungono o rimuovono la stringa specificata
• git diff -G<regex> - Cerca modifiche che corrispondono al pattern regex specificato
• git diff --pickaxe-all - Quando usi -S o -G, mostra tutte le modifiche nel file, non solo quelle corrispondenti

Opzioni di formato

• git diff --patch-with-stat - Mostra patch e riepilogo delle statistiche
• git diff --compact-summary - Mostra il riepilogo delle statistiche in formato compatto
• git diff --numstat - Mostra statistiche in un formato adatto alle macchine
• git diff --summary - Mostra il riepilogo di creazione/eliminazione

Queste opzioni possono essere combinate per creare confronti potenti e mirati. Ad esempio, per vedere le modifiche a livello di parola in un file specifico ignorando gli spazi bianchi:

git diff --color-words -w -- analysis.py

Oppure per trovare tutti i punti in cui una specifica funzione potrebbe essere stata aggiunta o rimossa:

git diff -S"def perform_advanced_analysis" main feature/advanced-analytics

Capire queste opzioni ti aiuta a tagliare il rumore e a concentrarti precisamente sui cambiamenti che contano, rendendo più efficienti i workflow di revisione e analisi del codice. Che tu stia cercando bug, preparando una pull request o semplicemente cercando di capire cosa è cambiato, l’opzione giusta di git diff può rendere il compito molto più semplice.

Conclusione

In questo articolo abbiamo esplorato git diff come comando versatile per visualizzare le modifiche al codice. Abbiamo visto come confrontare i file di lavoro con le modifiche in stage, esaminare le differenze tra branch e commit e usare comandi specializzati per approfondire. Integrare git diff nel tuo workflow aiuta a costruire commit più puliti, intercettare i problemi in anticipo e facilitare code review migliori. 

Che tu lavori da solo o in team, padroneggiare git diff ti porta dal semplice scrivere codice a comprendere come la tua codebase evolve nel tempo.

Per continuare a costruire la tua competenza con Git, dai un’occhiata a queste risorse preziose: 

• La completa Git Cheat Sheet per un riferimento rapido
• Introduction to Git per i principianti che vogliono consolidare le basi
• Il pratico GitHub and Git Tutorial for Beginners per un apprendimento pratico
• Intermediate Git per far progredire le tue abilità con strategie di branching e tecniche di collaborazione
• Foundations of Git per approfondimenti sul modello interno di Git e workflow avanzati. 

Queste risorse ti aiuteranno a costruire su quanto hai imparato su git diff e a portare la tua padronanza del controllo di versione al livello successivo.