Padroneggiare la Configurazione Utente di Git: Nome, Email e Impostazioni Predefinite dell'Editor

La configurazione utente di Git sembra noiosa fino alla prima volta che i tuoi commit di lavoro appaiono con l'indirizzo email sbagliato, il grafico dei contributi della tua azienda perde metà delle tue modifiche, o Git apre un editor che non sai come chiudere. La soluzione è solitamente semplice: imposta deliberatamente il tuo nome, email ed editor, poi impara come sovrascriverli per un singolo repository.

La parte importante non è memorizzare ogni flag di git config. È capire da dove Git legge la configurazione e come verificare il valore finale che Git utilizzerà prima di fare un commit.

Comprendere i Livelli di Configurazione di Git

Git utilizza una gerarchia di file di configurazione. Le impostazioni definite a un livello superiore possono essere sovrascritte da quelle definite a un livello inferiore. Comprendere questi livelli ti consente di applicare le impostazioni in modo granulare o universale.

Ci sono tre livelli di configurazione principali:

Livello di Sistema (--system): Si applica a ogni utente e a ogni repository sull'intera macchina. Viene usato raramente per l'identità utente, a meno che non si gestisca un server di build dedicato.
Livello Globale (--global): Si applica a tutti i repository posseduti dall'utente corrente sulla macchina. Qui è dove tipicamente imposti il tuo user.name e user.email primari.
Livello Locale (--local): Si applica solo al repository specifico in cui ti trovi attualmente. Questo ti permette di usare un'identità diversa per un progetto specifico (es. lavoro vs. personale).

Visualizzare le Impostazioni di Configurazione Correnti

Prima di apportare modifiche, è utile vedere cosa Git è attualmente configurato per usare. Puoi elencare le impostazioni per tutti i livelli o solo per uno specifico:

# Visualizza tutte le impostazioni su tutti i livelli
git config --list

# Visualizza solo le impostazioni globali
git config --global --list

Configurare la Tua Identità Utente (Nome e Email)

Il tuo nome e indirizzo email sono le informazioni utente più critiche memorizzate in Git. Identificano chi ha apportato la modifica.

1. Impostare l'Identità Utente Globale

Per la maggior parte degli utenti, impostare nome ed email a livello globale è il primo passo consigliato. Questo assicura che tutti i tuoi progetti futuri portino questa identità predefinita. Sostituisci i segnaposto con le tue informazioni reali.

Impostare il Nome:

git config --global user.name "Il Tuo Nome Completo"

Impostare l'Email:

È altamente consigliato usare l'indirizzo email associato al tuo account GitHub/GitLab/Bitbucket, specialmente se usi chiavi SSH o firma dei commit.

git config --global user.email "[email protected]"

Buona Pratica: Usa l'esatto indirizzo email collegato al tuo provider di hosting per assicurarti che i contributi appaiano correttamente sulle piattaforme remote.

2. Sovrascrivere l'Identità per un Repository Specifico (Livello Locale)

A volte, potresti contribuire a un progetto che richiede un'attribuzione specifica (es. usare un'email di lavoro per un repository cliente). Puoi sovrascrivere le impostazioni globali solo all'interno di quel repository.

Naviga nella directory radice del repository ed esegui i comandi di configurazione senza il flag --global:

# Naviga nella directory del tuo progetto
cd ~/progetti/progetto-cliente-alfa

# Imposta un nome specifico per questo repository
git config user.name "Nome di Lavoro"

# Imposta un'email specifica per questo repository
git config user.email "[email protected]"

Quando fai un commit all'interno di questo repository, Git userà queste impostazioni locali invece di quelle globali.

Come Git Sceglie l'Identità

Quando Git elabora un commit, controlla i livelli in ordine: Locale -> Globale -> Sistema. La prima impostazione che trova per user.name o user.email è quella usata.

Configurare il Tuo Editor di Testo Predefinito

Quando Git ha bisogno di input da te—come quando scrivi un messaggio di commit, un'istruzione di rebase, o una nota di risoluzione di conflitto di merge—apre il tuo editor di testo configurato. Di default, potrebbe essere un editor terminale di base come vi o vim, che può essere impegnativo per i nuovi utenti.

Impostare la Preferenza dell'Editor Globale

Puoi configurare Git per usare il tuo editor preferito su tutte le tue macchine o progetti usando il flag --global.

Usare VS Code come Editor

Se preferisci Visual Studio Code e hai installato l'integrazione da riga di comando (code), impostalo come segue:

git config --global core.editor "code --wait"

Il flag --wait è cruciale; dice a Git di mettere in pausa l'esecuzione fino a quando non chiudi il file aperto in VS Code, assicurando che il messaggio di commit sia finalizzato.

Usare Sublime Text come Editor

Per gli utenti di Sublime Text:

git config --global core.editor "subl -n -w"

Usare Nano o Vim (Se già familiari)

Se preferisci un editor terminale semplice:

# Per Nano
git config --global core.editor "nano"

# Per Vim (spesso il default)
git config --global core.editor "vim"

Testare la Tua Configurazione dell'Editor

Il modo più semplice per testare se la configurazione dell'editor funziona è avviare un amend che richiede un messaggio, o creare un commit senza fornire il flag -m:

# Crea un file fittizio e prova a fare un commit senza -m
touch filetemp.txt
git add filetemp.txt
git commit 
# Questo dovrebbe aprire il tuo editor appena configurato.

Correggere un'Identità Errata Esistente

Cambiare user.name e user.email influisce sui commit futuri. Non riscrive i commit già esistenti. Se il tuo ultimo commit ha l'autore sbagliato e non lo hai ancora inviato, puoi modificarlo dopo aver corretto la configurazione:

git config user.name "Nome Corretto"
git config user.email "[email protected]"
git commit --amend --reset-author

Se il commit errato è già stato inviato a un branch condiviso, fai attenzione. Riscrivere la storia pubblicata può disturbare altre persone. Per un branch privato, un amend e un force push possono essere accettabili:

git push --force-with-lease

Per un branch condiviso, la risposta più sicura è spesso lasciare la storia com'è e correggere l'identità per i commit futuri. Se molti commit necessitano di riparazione, usa uno strumento di riscrittura della storia solo dopo aver coordinato con il team.

Verificare da Dove Proviene un Valore

Quando Git si comporta in modo strano, git config --list può essere troppo rumoroso. Usa --show-origin così Git ti dice quale file ha fornito ogni valore:

git config --show-origin --list

Potresti vedere un output come:

file:/Users/alex/.gitconfig    [email protected]
file:.git/config               [email protected]

Ciò significa che il valore locale del repository vince nel repo corrente. Questo è il modo più veloce per diagnosticare "Ho cambiato la mia email globale ma Git usa ancora quella vecchia".

Puoi anche chiedere un singolo valore:

git config --show-origin user.email

Una Configurazione Lavoro e Personale che Regge

Un modello comune è mantenere un'identità globale personale e sovrascrivere i repository di lavoro localmente:

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

cd ~/lavoro/payments-api
git config user.email "[email protected]"

Alcuni team preferiscono cloni separati in directory separate. Le versioni più recenti di Git supportano inclusioni condizionali, che possono caricare automaticamente una configurazione di lavoro per repository sotto un percorso:

# ~/.gitconfig
[user]
    name = Alex Rivera
    email = [email protected]

[includeIf "gitdir:~/lavoro/"]
    path = ~/.gitconfig-lavoro

# ~/.gitconfig-lavoro
[user]
    email = [email protected]

Le regole esatte di corrispondenza dei percorsi possono essere un po' sorprendenti tra piattaforme, quindi testalo all'interno di un repository reale:

cd ~/lavoro/un-repo
git config --show-origin user.email

Problemi dell'Editor che Puoi Evitare

L'impostazione core.editor conta principalmente quando Git ha bisogno di un messaggio o di un file di istruzioni: commit di merge, rebase interattivi, modifiche di commit e commit senza -m. Se Git apre Vim e non ti trovi a tuo agio lì, può sembrare che il comando sia bloccato.

Per VS Code, il flag --wait non è opzionale:

git config --global core.editor "code --wait"

Senza --wait, Git potrebbe aprire il file e continuare immediatamente prima che tu finisca di scrivere il messaggio. Per server solo terminale, nano è spesso meno sorprendente:

git config --global core.editor "nano"

Puoi testare l'editor senza creare una modifica reale al progetto:

git commit --allow-empty

Scrivi un messaggio di test, salva, e poi elimina il commit vuoto se non lo vuoi:

git reset --soft HEAD~1

Firma dei Commit e Account di Hosting

La tua email Git è separata dall'autenticazione. Le chiavi SSH, i token di accesso personale e il login del browser decidono se puoi inviare. user.email decide quale email dell'autore viene scritta nell'oggetto del commit.

I provider di hosting di solito abbinano i commit al tuo account tramite indirizzo email. Se usi un'email per la privacy, imposta quell'esatto indirizzo:

git config --global user.email "[email protected]"

Se la tua organizzazione richiede commit firmati, l'identità è solo una parte della configurazione. Potresti anche aver bisogno di user.signingkey, commit.gpgsign, o la configurazione della firma SSH. Tienilo separato dalla configurazione base di nome/email in modo da poter fare debug di un livello alla volta.

Autore, Committer e Sovrascritture dell'Ambiente

Git memorizza sia un autore che un committer su ogni commit. La maggior parte delle volte sono la stessa persona. Differiscono quando qualcuno applica una patch da un altro sviluppatore, fa rebase di commit, o modifica un commit originariamente scritto da qualcun altro.

Puoi vedere entrambi i campi con:

git log --format=fuller -1

Questo output è utile quando qualcuno dice "Git ha usato l'email sbagliata" ma il normale log a una riga mostra solo l'autore. Il committer potrebbe essere diverso perché un manutentore ha applicato la patch, o perché un rebase ha ricreato il commit.

Git può anche leggere l'identità da variabili d'ambiente:

GIT_AUTHOR_NAME="Build Bot" \
GIT_AUTHOR_EMAIL="[email protected]" \
git commit -m "Aggiorna file generati"

I sistemi CI a volte usano questo modello. Va bene quando è intenzionale, ma è confuso quando una pipeline perde queste variabili in una shell di sviluppatore o in uno script locale. Se Git ignora la tua configurazione, controlla l'ambiente:

env | rg '^GIT_(AUTHOR|COMMITTER)'

Rimuovi le sovrascritture accidentali prima di fare commit:

unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL

Una Piccola Politica di Team che Previene una Storia Disordinata

Per i team, la migliore politica di configurazione utente di Git è solitamente breve:

Usa il tuo nome reale o lo stesso handle che il tuo team riconosce.
Usa un'email aziendale per i repository aziendali.
Usa un'email verificata del provider di hosting in modo che i commit si colleghino all'account giusto.
Non riscrivere la storia condivisa solo per pulire i metadati dell'autore vecchi, a meno che il team non sia d'accordo.
Documenta il core.editor preferito solo se i tuoi script di onboarding dipendono da esso.

Puoi aggiungere un controllo pre-commit o pre-push per i domini email, ma mantienilo amichevole. Un hook locale che blocca ogni commit perché qualcuno sta lavorando in coppia da una macchina diversa creerà attrito. Una politica lato server o un controllo CI sui branch protetti è solitamente più facile da gestire.

Ecco un semplice controllo locale che puoi eseguire manualmente prima di inviare codice di lavoro:

git config user.email
git log --format='%h %ae %s' origin/main..HEAD

Se qualche commit mostra un'email personale su un branch aziendale, correggilo prima di aprire la pull request. È molto più facile che riparare un branch unito in seguito.

Risolvere le Sorprese Comuni della Configurazione

Se git config --global user.email mostra il valore giusto ma i commit usano ancora qualcos'altro, controlla se ti trovi all'interno di un repository con una sovrascrittura locale:

git config --local user.email
git config --show-origin user.email

Se il valore locale è sbagliato, sostituiscilo o rimuovilo:

git config user.email "[email protected]"
git config --unset user.email

Rimuovere il valore locale fa sì che Git torni al valore globale. Questo è spesso più pulito che impostare lo stesso valore in ogni repository.

Se Git dice Author identity unknown, significa che Git non ha potuto trovare un user.name e user.email utilizzabili dalla configurazione o dall'ambiente. Imposta entrambi, non solo uno:

git config --global user.name "Alex Rivera"
git config --global user.email "[email protected]"

Su server condivisi, evita --system a meno che non gestisci la macchina per tutti. Un'identità a livello di sistema può far sì che utenti non correlati commettano accidentalmente come la stessa persona. Gli agenti di build sono l'eccezione principale, e anche lì è solitamente meglio configurare l'area di lavoro CI o l'account di servizio esplicitamente.

Lista di Controllo Rapida

Usa git config --global per impostazioni che si applicano ovunque, come la tua identità predefinita e l'editor.
Usa git config (senza flag) all'interno di un repository per sovrascrivere le impostazioni globali localmente.
Usa git config --show-origin --list quando hai bisogno di sapere quale file sta vincendo.
Usa git commit --amend --reset-author solo quando riscrivere il commit più recente è appropriato.
Usa --wait quando configuri editor grafici in modo che Git aspetti che tu finisca di modificare.