Personalizzare il Comportamento di Git: Configurazione, Alias e File Importanti

Personalizzare il comportamento di Git ti aiuta a rendere il controllo di versione quotidiano più veloce, sicuro e prevedibile. Con la giusta configurazione di Git, alias e file importanti, il tuo flusso di lavoro locale può corrispondere a come il tuo team costruisce effettivamente il software.

L'obiettivo non è creare una configurazione intelligente che nessun altro capisca. L'obiettivo è rimuovere gli attriti dalle attività comuni mantenendo i tuoi repository facili da controllare e supportare.

Come Funziona la Configurazione di Git

Git legge le impostazioni da diversi punti e l'impostazione più vicina vince. Questo è importante quando stai cercando di capire perché Git utilizza il nome sbagliato, l'editor, lo strumento di merge, le terminazioni di riga o il comportamento di firma.

I tre principali ambiti di configurazione sono:

• Sistema: si applica a ogni utente sulla macchina.
• Globale: si applica al tuo account utente.
• Locale: si applica solo al repository corrente.

Di solito lavorerai con impostazioni globali e locali. Le impostazioni globali sono buone per la tua identità, l'editor predefinito e gli alias comuni. Le impostazioni locali sono migliori per il comportamento specifico del repository, come un indirizzo email diverso per i progetti di lavoro.

Usa questi comandi per ispezionare da dove proviene un'impostazione:

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

Ad esempio, potresti usare la tua email personale a livello globale:

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

Poi, all'interno di un repository di lavoro, sovrascrivi solo l'email:

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

Questo evita di commettere accidentalmente un commit in un repository aziendale con un'identità personale. Rende anche la cronologia dei commit più pulita per conformità, proprietà e revisione del codice.

Se desideri un ripasso più approfondito sulle impostazioni di identità, consulta padroneggiare la configurazione utente di Git.

Impostazioni Utili da Personalizzare per Prime

Inizia con impostazioni che migliorano la chiarezza e prevengono piccoli errori. Non hai bisogno di un file di configurazione enorme per ottenere un vero valore.

Una buona base include il nome del ramo predefinito:

git config --global init.defaultBranch main

Imposta il tuo editor preferito in modo che Git possa aprire messaggi di commit, piani di rebase e note di merge in uno strumento che usi effettivamente:

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

Se lavori su macOS, Linux e Windows, le terminazioni di riga meritano attenzione. Molti team scelgono di mantenere le terminazioni di riga normalizzate nel repository e lasciare che l'editor di ogni sviluppatore gestisca la visualizzazione. Un'impostazione comune di Windows è:

git config --global core.autocrlf true

Su macOS o Linux, i team spesso usano:

git config --global core.autocrlf input

Non modificare le impostazioni delle terminazioni di riga con noncuranza in un repository esistente. Se vedi un enorme diff in cui ogni riga appare modificata, fermati e ispeziona .gitattributes prima di fare commit.

Puoi anche rendere l'output di Git più leggibile:

git config --global color.ui auto
git config --global column.ui auto
git config --global branch.sort -committerdate
git config --global tag.sort version:refname

Per tirare le modifiche, scegli il comportamento che il tuo team si aspetta:

git config --global pull.rebase false

o:

git config --global pull.rebase true

Nessuna delle due opzioni è universalmente corretta. I pull basati su merge preservano i commit di merge. I pull basati su rebase mantengono una cronologia locale lineare. La parte importante è scegliere intenzionalmente e documentare le aspettative del team.

Creare Alias di Git che Fanno Risparmiare Tempo

Gli alias di Git trasformano comandi lunghi in scorciatoie brevi e memorabili. Sono particolarmente utili per comandi che esegui molte volte al giorno.

Ecco alias pratici che rimangono leggibili:

git config --global alias.st status
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"

Dopo di che, git st ti dà lo stato e git unstage file.txt rimuove un file dall'area di staging senza toccare la tua copia di lavoro.

Gli alias di log sono dove molti team ottengono il massimo valore:

git config --global alias.lg "log --oneline --decorate --graph --all"

Ora puoi eseguire:

git lg

Questo ti dà un grafico compatto di rami, tag e commit. È utile prima di fare rebase, merge o pulire i rami locali.

Mantieni gli alias abbastanza semplici in modo che un compagno di squadra possa indovinare cosa fanno. Un alias come git save potrebbe significare commit, stash o qualcos'altro a seconda della persona che lo ha creato. Un alias come git unstage è ovvio.

Puoi rivedere i tuoi alias con:

git config --global --get-regexp '^alias\.'

Per altri esempi, consulta creare alias personalizzati di Git.

File Importanti di Git che Dovresti Conoscere

Il comportamento di Git non è controllato solo da git config. Diversi file del repository modellano cosa viene tracciato, ignorato, normalizzato e protetto.

Il file più comune è .gitignore. Dice a Git quali file non tracciati ignorare. Le voci tipiche includono output di build, file di ambiente locali, cartelle dell'editor e cache delle dipendenze:

node_modules/
dist/
.env
.DS_Store

Fai attenzione con pattern ampi. Ignorare *.json potrebbe nascondere file generati, ma può anche nascondere configurazioni importanti. Quando possibile, ignora directory o nomi di file specifici.

Il file .gitattributes controlla come Git tratta i tipi di file. È utile per terminazioni di riga, file generati, comportamento di linguist e strategie di merge:

* text=auto
*.sh text eol=lf
*.bat text eol=crlf

Questo è particolarmente utile in team che utilizzano sistemi operativi diversi. Riduce i diff rumorosi e impedisce che gli script si rompano a causa delle terminazioni di riga sbagliate.

Il file .git/config memorizza la configurazione del repository locale. Normalmente lo modifichi con git config --local, ma leggerlo può aiutarti a risolvere problemi con remote, tracciamento dei rami e opzioni specifiche del repository.

Gli hook di Git risiedono in .git/hooks/. Possono eseguire script prima di commit, push, merge e altri eventi. Per impostazione predefinita, gli hook sono locali e non vengono commessi come script attivi. I team che si affidano agli hook spesso usano uno script di configurazione o un gestore di hook per installarli in modo coerente.

Quando Chiedere Aiuto

La maggior parte delle modifiche alla configurazione di Git sono sicure, ma alcune possono disturbare un team se applicate senza contesto. Chiedi a un ingegnere senior, un ingegnere DevOps o il proprietario del repository prima di modificare le regole delle terminazioni di riga, i driver di merge, i requisiti di firma o il comportamento condiviso degli hook.

Dovresti anche chiedere aiuto se i commit appaiono con l'identità sbagliata in un repository protetto. Correggere i metadati dell'autore dopo che il codice è stato inviato può richiedere la riscrittura della cronologia, che influisce su tutti coloro che usano quel ramo.

Se Git improvvisamente si comporta diversamente, inizia con git config --list --show-origin. Quel singolo comando spesso spiega il mistero più velocemente che indovinare.

Una personalizzazione ponderata fa sembrare Git meno ripetitivo senza nascondere cosa sta succedendo. Mantieni i tuoi alias chiari, tieni documentate le regole del repository e usa le impostazioni locali quando un progetto ha bisogno di un comportamento diverso dal resto della tua macchina.