Configurazione: identità, editor, alias, default

Git funziona anche senza configurazione curata, ma ti farà perdere tempo nei momenti peggiori: editor sbagliato durante un merge, identità errata nei commit, branch iniziale con nome diverso da quello del team, pull che crea merge inattesi.

Configurare Git significa ridurre attrito e rendere prevedibile il comportamento quotidiano.

Perché questa lezione conta

Molti sviluppatori imparano Git comando per comando e lasciano la configurazione al caso. Il risultato è un ambiente fragile: ogni macchina si comporta in modo leggermente diverso, ogni repo ha default impliciti, ogni collaboratore usa alias e convenzioni diverse.

Una buona configurazione non sostituisce il modello mentale. Lo rende più facile da applicare.

Obiettivo operativo

Alla fine della lezione devi avere una configurazione globale minima, sapere quando usare config locale e avere alias che aumentano leggibilità senza nascondere Git.

I tre livelli di config

Git legge configurazioni da più livelli:

git config --system --list
git config --global --list
git config --local --list

System. Valida per tutti gli utenti della macchina. Di solito la tocchi raramente.

Global. Valida per il tuo utente. Qui metti identità, editor, alias personali.

Local. Valida solo per il repo corrente. Qui metti eccezioni: email aziendale diversa, regole di pull specifiche, firma commit obbligatoria.

Per capire da dove arriva una regola:

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

Identità

Ogni commit contiene autore e committer. Configurare identità non è cosmetica: è tracciabilità.

git config --global user.name "Nome Cognome"
git config --global user.email "nome@example.com"

Se lavori su progetti personali e aziendali, imposta email diversa a livello local:

git config --local user.email "nome@azienda.it"

Evita commit aziendali con email personale o viceversa. Sembra un dettaglio finché non devi auditare una storia.

Editor e branch default

Imposta un editor che sai usare anche sotto pressione:

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

Il --wait è importante: Git deve aspettare che tu chiuda il file di messaggio.

Imposta branch iniziale:

git config --global init.defaultBranch main

Così i nuovi repo non partono con default diversi da quelli del team.

Pull e merge

Uno dei default più delicati:

git config --global pull.rebase true

Con questa scelta, git pull prova a fare fetch + rebase invece di fetch + merge. Può aiutare a mantenere storia lineare sui branch personali, ma non è una legge universale. Il team deve sapere cosa usa.

Altra opzione utile:

git config --global fetch.prune true

Rimuove i riferimenti remoti a branch cancellati sul server, riducendo rumore.

Alias utili

Gli alias devono accorciare comandi che capisci, non creare una lingua privata incomprensibile.

git config --global alias.st "status --short --branch"
git config --global alias.lg "log --graph --oneline --decorate --all"
git config --global alias.last "log -1 --stat"
git config --global alias.unstage "restore --staged"

Evita alias distruttivi o troppo criptici. git nah che fa reset hard può sembrare simpatico, ma prima o poi farà danni.

Template commit

Puoi impostare un template:

git config --global commit.template ~/.gitmessage

Esempio:

tipo(scope): oggetto breve

Perché:

Dettagli:

Verifiche:

Non tutti i commit hanno bisogno di body lungo, ma il template ricorda di scrivere il perché quando serve.

Laboratorio guidato

Fai un audit:

1. esegui git config --global --list --show-origin;
2. verifica identità;
3. imposta editor;
4. scegli branch default;
5. aggiungi massimo quattro alias;
6. crea un repo demo e verifica che tutto funzioni.

Poi salva la configurazione utile in un repo dotfiles o in una nota versionata.

Output atteso

Un .gitconfig personale commentato:

[user]
  name = ...
  email = ...
[init]
  defaultBranch = main
[alias]
  st = status --short --branch
  lg = log --graph --oneline --decorate --all

Errori comuni

Alias incomprensibili. Se nessuno capisce cosa fanno, non aiutano il team.

Config globale per eccezioni locali. Email aziendale, regole particolari e signing di progetto spesso stanno meglio nel repo specifico.

Editor non bloccante. Se Git apre l’editor e continua senza aspettare, il comando fallisce o crea confusione.

Checklist di verifica

• user.name e user.email sono corretti;
• so distinguere config global e local;
• ho un alias leggibile per log grafico;
• il mio editor funziona con commit e merge;
• so vedere l’origine di una configurazione.

Collegamenti

• Modulo: Fondamenti e modello mentale — lezione 4 del corso.
• Gli alias tornano nel modulo 2, dove status, diff e log diventano routine.