--- /dev/null
++++
+title = "The Git Config Settings I Actually Use"
+author = "Danilo M."
+type = "tech"
+date = "2026-04-28T19:53:46+02:00"
+draft = false
+excerpt = "A tour through my ~/.gitconfig, covering the settings I've grown to rely on daily and why each one earns its place."
+tags = ["git", "workflow", "linux", "gpg", "hugo", "configuration", "howto"]
+categories = ["DIY", "Code"]
++++
+
+A few years back, I set up a two-repository system for this site: one repo for content, another for the theme (living as a submodule). It's a clean architecture in theory, but in practice, managing two repos means you're constantly juggling branch updates, resolving submodule pointer conflicts, and pushing to two remotes in sequence. I started carrying around a `.gitconfig` file between machines, tweaking it bit by bit as I discovered settings that eliminated friction.
+
+This isn't a guide to every git option, that would be a book. Instead, it's a personal tour through the settings I've actually integrated into my workflow, why they matter, and what changed once each one was on.
+
+<!--more-->
+
+## The Setup Glue: `push.autoSetupRemote` and `pull.rebase`
+
+These two live together because they're about the boundaries of your branches: pushing them up and pulling them back down.
+
+### push.autoSetupRemote
+
+The old frustration: cut a new branch locally, write code, run `git push`, and get:
+
+```
+fatal: The current branch feature/my-new-branch has no upstream branch.
+To push the current and set the upstream branch, use:
+
+ git push --set-upstream origin feature/my-new-branch
+```
+
+It's boilerplate ceremony every time you push a new branch. The fix:
+
+```ini
+[push]
+ autoSetupRemote = true
+```
+
+Now `git push` on a new branch just works. It infers the tracking branch automatically. The first time I used this with Hugo content branches, cutting `content/new-article` on Monday and pushing immediately, I realized I'd eliminated maybe fifty typos a year of `--set-upstream`.
+
+### pull.rebase
+
+Linear history matters more on a single-author site. Without `pull.rebase = true`, pulling changes creates merge commits like "Merge branch 'main' of origin/main" even when you're just syncing. These commits don't represent work; they're noise. They clutter `git log`, make bisecting slower, and add confusion to the graph.
+
+```ini
+[pull]
+ rebase = true
+```
+
+With this on, pulling rebases your local work on top of the remote tip. When you're managing a Hugo site with a theme submodule, this is especially helpful: submodule pointer updates stay tidy in the log instead of hiding inside merge commits.
+
+## Identity and Trust: `commit.gpgsign`
+
+GPG signing commits isn't about compliance or passing audits. It's about provenance. Every commit on my repos carries my cryptographic signature, proof that it came from me and hasn't been tampered with.
+
+```ini
+[user]
+ signingkey = YOUR_GPG_KEY_ID
+ email = danix@danix.xyz
+ name = Danilo M.
+
+[commit]
+ gpgsign = true
+```
+
+The first time you set this up, know that `gpg-agent` needs to be running and your key needs to be imported locally. Once both are in place, every commit is signed automatically. If you want to dive deeper into GPG keys, I wrote about [managing passwords with password-store](/en/articles/manage-your-passwords-with-password-store/), which covers key setup.
+
+## Reducing Friction: `help.autocorrect`, `fetch.prune`, and `fetch.prunetags`
+
+Three small settings that save daily typing and mental overhead.
+
+### help.autocorrect
+
+Typos happen. I often type `git statsu` instead of `git status`, or `git comit` instead of `git commit`. The old behavior is an error message and a suggested fix. With:
+
+```ini
+[help]
+ autocorrect = 10
+```
+
+Git autocorrects and runs the command after a 1-second countdown:
+
+```
+$ git statsu
+WARNING: You called a Git command named 'statsu', which does not exist.
+Continuing in 0.9 seconds, assuming that you meant 'status'.
+```
+
+The `10` here means 1 second (git measures in tenths). It's long enough to notice and interrupt if the correction is wrong, but short enough not to interrupt workflow.
+
+### fetch.prune and fetch.prunetags
+
+When teammates delete branches on the remote, stale refs accumulate in your local repository. These settings clean them up:
+
+```ini
+[fetch]
+ prune = true
+ prunetags = true
+```
+
+Now `git fetch` silently removes local branches that no longer exist upstream, and does the same for tags. For a Hugo theme repo, old release tags get cleaned up on the server, and `prunetags` means they don't linger in your local `git tag` output.
+
+## When Conflicts Happen: `merge.conflictstyle` and `rerere`
+
+Two settings that make merge conflicts less painful.
+
+### merge.conflictstyle = zdiff3
+
+Conflict markers normally show you two sides:
+
+```
+<<<<<<< HEAD
+your code
+=======
+their code
+>>>>>>> branch
+```
+
+You see what you wrote and what they wrote, but not what you both started from. The `zdiff3` conflict style shows the ancestor:
+
+```
+<<<<<<< HEAD
+your code
+||||||| base
+original code
+=======
+their code
+>>>>>>> branch
+```
+
+The `||||||| base` section is what both sides changed from. Now you can see the full story: you changed this line to X, they changed it to Y, and the original was Z. Intent becomes obvious.
+
+```ini
+[merge]
+ conflictstyle = zdiff3
+```
+
+### rerere.enabled and rerere.autoupdate
+
+`rerere` stands for "reuse recorded resolution." When you resolve a conflict manually, git remembers the resolution. The next time you hit the same conflict:
+
+```ini
+[rerere]
+ enabled = true
+ autoupdate = true
+```
+
+Git resolves it automatically. This is invaluable when rebasing a content branch over a main that includes a submodule pointer update. The first time there's a conflict in the submodule reference, you resolve it. On a second branch with the same conflict, `rerere` handles it silently, and `autoupdate` stages the resolution so you don't have to `git add` it manually.
+
+## Looking Around: Branch Display, Logs, and Diffs
+
+Four settings that make reading your repository history faster.
+
+### branch.sort and column.ui
+
+```ini
+[branch]
+ sort = -committerdate
+
+[column]
+ ui = auto
+```
+
+By default, `git branch` lists branches alphabetically. Useless past ten branches. The `-committerdate` sort shows newest first, so the branch you're probably about to switch to is at the top.
+
+`column.ui = auto` displays branches in multiple columns when your terminal is wide enough, cutting down on scrolling through a long list.
+
+### log.abbrevCommit and log.follow
+
+```ini
+[log]
+ abbrevCommit = true
+ follow = true
+```
+
+`abbrevCommit` shows short SHAs (7 chars) instead of full 40-character hashes. Cleaner logs, faster to read.
+
+`follow` tracks files through renames. When you run `git log -- path/to/article.md` and that file was once named `old-article.md`, log doesn't break, it follows the file through the rename and shows the full history.
+
+### diff.mnemonicPrefix, diff.renames, and diff.wordRegex
+
+```ini
+[diff]
+ mnemonicPrefix = true
+ renames = true
+ wordRegex = [^[:space:]]
+```
+
+`mnemonicPrefix` changes the diff headers from `a/` and `b/` to more descriptive labels like `i/` (index), `w/` (working tree), `o/` (object), `c/` (commit). More information at a glance.
+
+`renames = true` detects file renames and shows them as `file.old => file.new` instead of a delete and a create. Cleaner diffs.
+
+`wordRegex` defines what counts as a "word" in word-level diffs (`git diff --word-diff`). The pattern `[^[:space:]]` treats any non-whitespace as a word, which means punctuation gets its own boundaries, useful for prose-heavy files like Markdown articles.
+
+## Shorthand That Earns Its Place: Aliases
+
+I keep aliases minimal on purpose. Aliases that hide what git is doing are noise; these two are worth the keystroke savings.
+
+### lg: Pretty-print log with graph
+
+```ini
+[alias]
+ lg = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
+```
+
+Running `git lg` shows a colored graph with commit hashes, dates, messages, authors, and branch pointers:
+
+```
+* abc1234 - (3 hours ago) Add git config article - Danilo M. (HEAD -> master)
+* def5678 - (1 day ago) Fix theme CSS - Danilo M.
+|\
+| * ghi9012 - (2 days ago) WIP: new feature - Danilo M. (content/draft)
+|/
+* jkl3456 - (5 days ago) Bump theme submodule - Danilo M. (origin/master)
+```
+
+Much better than plain `git log`.
+
+### sw: Switch shorthand
+
+```ini
+[alias]
+ sw = switch
+```
+
+`git sw main` is faster than `git switch main`, and `git sw -c feature/new` creates and switches in one command.
+
+## A Typical Day
+
+Here's how these settings work together in practice.
+
+Morning: sync with the repo. `git fetch` fires silently in the background, `fetch.prune` and `prunetags` cleaning up any deleted branches and old tags without you thinking about it.
+
+I'm starting the week's Hugo article. Cut a new content branch:
+
+```bash
+git sw -c content/git-config-deep-dive
+```
+
+No typing `--set-upstream` later. `push.autoSetupRemote` has me covered.
+
+Write, commit. The commit is GPG-signed automatically. No extra steps.
+
+```bash
+git commit -m "Add first draft of git config article"
+```
+
+Push when done:
+
+```bash
+git push
+```
+
+No upstream error. Just works.
+
+Later, the main branch gets a theme submodule update. I rebase my work on top:
+
+```bash
+git fetch
+git rebase main
+```
+
+There's a conflict in the submodule pointer, the theme repo moved forward. `merge.conflictstyle = zdiff3` shows me exactly what changed. I resolve it once.
+
+Later, a second branch has the same submodule conflict. `rerere` remembers my resolution and applies it automatically with `rerere.autoupdate`. No re-resolving.
+
+Before merging back to main, check the graph:
+
+```bash
+git lg
+```
+
+Pretty output shows the timeline clearly.
+
+Merge to main:
+
+```bash
+git switch main
+git merge content/git-config-deep-dive
+```
+
+If there's a conflict here (unlikely given we rebased), `zdiff3` shows the ancestor context.
+
+Done. All the settings worked together transparently.
+
+## The Full Config
+
+Here's the complete block as it sits in my `~/.gitconfig`:
+
+```ini
+[user]
+ name = Danilo M.
+ email = danix@danix.xyz
+ signingkey = YOUR_KEY_ID_HERE
+
+[pull]
+ rebase = true
+
+[push]
+ autoSetupRemote = true
+
+[commit]
+ gpgsign = true
+
+[help]
+ autocorrect = 10
+
+[fetch]
+ prune = true
+ prunetags = true
+
+[merge]
+ conflictstyle = zdiff3
+
+[rerere]
+ enabled = true
+ autoupdate = true
+
+[branch]
+ sort = -committerdate
+
+[column]
+ ui = auto
+
+[log]
+ abbrevCommit = true
+ follow = true
+
+[diff]
+ mnemonicPrefix = true
+ renames = true
+ wordRegex = [^[:space:]]
+
+[alias]
+ lg = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
+ sw = switch
+```
+
+Copy what you need. Leave what doesn't fit your workflow.
+
+## A Config That Evolves
+
+This isn't the "correct" git configuration, it's the one that fits how I work. I've been refining it for years, and it'll keep evolving as I hit new friction points and discover new settings. The point isn't to follow mine exactly, but to think about what's slowing you down and look for the git setting that fixes it.
+
+If you use any of these settings, or if you've found others that changed your workflow, let me know in the comments. I'm always curious how other people configure their tools.
--- /dev/null
++++
+title = "Le Impostazioni Git che Uso Davvero"
+author = "Danilo M."
+type = "tech"
+date = "2026-04-28T19:53:46+02:00"
+draft = false
+excerpt = "Un giro nel mio ~/.gitconfig: le impostazioni su cui mi appoggio ogni giorno e perché ognuna si guadagna il suo posto."
+tags = ["git", "workflow", "linux", "gpg", "hugo", "configurazione", "howto"]
+categories = ["DIY", "Code"]
++++
+
+Qualche anno fa ho impostato un sistema a due repository per questo sito: uno per i contenuti, l'altro per il tema (come submodule). È un'architettura pulita in teoria, ma in pratica gestire due repository significa destreggiarsi continuamente tra aggiornamenti di branch, conflitti sul puntatore del submodule e push su due remote in sequenza. Ho cominciato a portarmi in giro un file `.gitconfig` tra macchine diverse, modificandolo un po' alla volta man mano che scoprivo impostazioni che eliminano l'attrito.
+
+Questo non è una guida a ogni opzione di git, ci vorrebbe un libro. È invece un tour personale delle impostazioni che ho davvero integrato nel mio flusso di lavoro, perché contano e cosa è cambiato da quando sono attive.
+
+<!--more-->
+
+## La Colla del Flusso: `push.autoSetupRemote` e `pull.rebase`
+
+Queste due stanno insieme perché riguardano i confini dei branch: come li mandi su e come li riporti giù.
+
+### push.autoSetupRemote
+
+La vecchia frustrazione: creare un branch locale, scrivere codice, eseguire `git push` e ricevere:
+
+```
+fatal: The current branch feature/my-new-branch has no upstream branch.
+To push the current and set the upstream branch, use:
+
+ git push --set-upstream origin feature/my-new-branch
+```
+
+Ogni volta la stessa cerimonia inutile. La soluzione:
+
+```ini
+[push]
+ autoSetupRemote = true
+```
+
+Ora `git push` su un nuovo branch funziona e basta. Git deduce il branch di tracciamento automaticamente. La prima volta che ho usato questa impostazione con i branch di contenuto Hugo, creando `content/nuovo-articolo` il lunedì e facendo subito push, ho capito di aver eliminato forse cinquanta digitazioni l'anno di `--set-upstream`.
+
+### pull.rebase
+
+La storia lineare conta di più su un sito a singolo autore. Senza `pull.rebase = true`, fare pull dei cambiamenti crea commit di merge come "Merge branch 'main' of origin/main" anche quando stai solo sincronizzando. Questi commit non rappresentano lavoro: sono rumore. Intasano `git log`, rendono il bisect più lento e aggiungono confusione al grafo.
+
+```ini
+[pull]
+ rebase = true
+```
+
+Con questa impostazione attiva, fare pull ribasa il lavoro locale sopra la punta remota. Quando gestisci un sito Hugo con un submodule del tema, questo è particolarmente utile: gli aggiornamenti del puntatore del submodule restano ordinati nel log invece di nascondersi dentro commit di merge.
+
+## Identità e Fiducia: `commit.gpgsign`
+
+Firmare i commit con GPG non riguarda la conformità o il superamento di audit. Riguarda la provenienza. Ogni commit sui miei repository porta la mia firma crittografica, la prova che viene da me e non è stata manomessa.
+
+```ini
+[user]
+ signingkey = IL_TUO_KEY_ID_GPG
+ email = danix@danix.xyz
+ name = Danilo M.
+
+[commit]
+ gpgsign = true
+```
+
+La prima volta che si configura, è necessario che `gpg-agent` sia in esecuzione e che la chiave sia importata localmente. Una volta fatto, ogni commit viene firmato automaticamente. Se vuoi approfondire le chiavi GPG, ho scritto di [gestire le password con password-store](/it/articles/manage-your-passwords-with-password-store/), che copre la configurazione delle chiavi.
+
+## Ridurre l'Attrito: `help.autocorrect`, `fetch.prune` e `fetch.prunetags`
+
+Tre piccole impostazioni che risparmiano digitazioni quotidiane e carichi mentali.
+
+### help.autocorrect
+
+I refusi capitano. Scrivo spesso `git statsu` invece di `git status`, o `git comit` invece di `git commit`. Il vecchio comportamento è un messaggio di errore con una correzione suggerita. Con:
+
+```ini
+[help]
+ autocorrect = 10
+```
+
+Git autocorregge ed esegue il comando dopo un conto alla rovescia di 1 secondo:
+
+```
+$ git statsu
+WARNING: You called a Git command named 'statsu', which does not exist.
+Continuing in 0.9 seconds, assuming that you meant 'status'.
+```
+
+Il `10` qui significa 1 secondo (git misura in decimi). È abbastanza lungo da notarlo e interrompere se la correzione è sbagliata, ma abbastanza breve da non spezzare il ritmo.
+
+### fetch.prune e fetch.prunetags
+
+Quando si eliminano branch sul remote, i riferimenti obsoleti si accumulano nel repository locale. Queste impostazioni li puliscono:
+
+```ini
+[fetch]
+ prune = true
+ prunetags = true
+```
+
+Ora `git fetch` rimuove silenziosamente i branch locali che non esistono più upstream, e fa lo stesso per i tag. Per un repository del tema Hugo, i vecchi tag di release vengono rimossi dal server, e `prunetags` fa sì che non restino nel tuo output di `git tag`.
+
+## Quando Arrivano i Conflitti: `merge.conflictstyle` e `rerere`
+
+Due impostazioni che rendono i conflitti di merge meno dolorosi.
+
+### merge.conflictstyle = zdiff3
+
+I marcatori di conflitto normalmente mostrano due lati:
+
+```
+<<<<<<< HEAD
+il tuo codice
+=======
+il loro codice
+>>>>>>> branch
+```
+
+Vedi cosa hai scritto tu e cosa hanno scritto loro, ma non da dove entrambi sono partiti. Lo stile di conflitto `zdiff3` mostra l'antenato comune:
+
+```
+<<<<<<< HEAD
+il tuo codice
+||||||| base
+codice originale
+=======
+il loro codice
+>>>>>>> branch
+```
+
+La sezione `||||||| base` è ciò che entrambi i lati hanno modificato. Ora vedi la storia completa: tu hai cambiato questa riga in X, loro in Y, e l'originale era Z. L'intenzione diventa ovvia.
+
+```ini
+[merge]
+ conflictstyle = zdiff3
+```
+
+### rerere.enabled e rerere.autoupdate
+
+`rerere` sta per "reuse recorded resolution" (riutilizza la risoluzione registrata). Quando risolvi un conflitto manualmente, git ricorda la risoluzione. La prossima volta che si presenta lo stesso conflitto:
+
+```ini
+[rerere]
+ enabled = true
+ autoupdate = true
+```
+
+Git lo risolve automaticamente. Questo è prezioso quando si ribasa un branch di contenuto su un main che include un aggiornamento del puntatore del submodule. La prima volta che c'è un conflitto nel riferimento del submodule, lo risolvi tu. Su un secondo branch con lo stesso conflitto, `rerere` lo gestisce silenziosamente, e `autoupdate` mette in staging la risoluzione così non devi fare `git add` manualmente.
+
+## Orientarsi: Visualizzazione Branch, Log e Diff
+
+Quattro impostazioni che rendono più veloce leggere la storia del repository.
+
+### branch.sort e column.ui
+
+```ini
+[branch]
+ sort = -committerdate
+
+[column]
+ ui = auto
+```
+
+Di default, `git branch` elenca i branch in ordine alfabetico. Inutile dopo dieci branch. L'ordinamento per `-committerdate` mostra i più recenti per primi, il branch su cui probabilmente stai per passare è in cima.
+
+`column.ui = auto` mostra i branch su più colonne quando il terminale è abbastanza largo, riducendo lo scorrimento di una lista lunga.
+
+### log.abbrevCommit e log.follow
+
+```ini
+[log]
+ abbrevCommit = true
+ follow = true
+```
+
+`abbrevCommit` mostra SHA corti (7 caratteri) invece degli hash completi da 40 caratteri. Log più puliti, più veloci da leggere.
+
+`follow` traccia i file attraverso i rename. Quando esegui `git log -- path/to/article.md` e quel file si chiamava prima `old-article.md`, il log non si interrompe, segue il file attraverso il rename e mostra la storia completa.
+
+### diff.mnemonicPrefix, diff.renames e diff.wordRegex
+
+```ini
+[diff]
+ mnemonicPrefix = true
+ renames = true
+ wordRegex = [^[:space:]]
+```
+
+`mnemonicPrefix` cambia le intestazioni dei diff da `a/` e `b/` a etichette più descrittive come `i/` (index), `w/` (working tree), `o/` (object), `c/` (commit). Più informazioni a colpo d'occhio.
+
+`renames = true` rileva i rename dei file e li mostra come `file.old => file.new` invece di una cancellazione e una creazione. Diff più puliti.
+
+`wordRegex` definisce cosa conta come "parola" nei diff a livello di parola (`git diff --word-diff`). Il pattern `[^[:space:]]` tratta qualsiasi carattere non-spazio come una parola, il che significa che la punteggiatura ottiene i propri confini, utile per file ricchi di testo come gli articoli Markdown.
+
+## Le Abbreviazioni che si Guadagnano il Posto: Alias
+
+Tengo gli alias al minimo di proposito. Gli alias che nascondono cosa fa git sono rumore; questi due valgono il risparmio di battiture.
+
+### lg: Log formattato con grafo
+
+```ini
+[alias]
+ lg = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
+```
+
+Eseguendo `git lg` si ottiene un grafo colorato con hash, date, messaggi, autori e puntatori ai branch:
+
+```
+* abc1234 - (3 hours ago) Aggiungo articolo git config - Danilo M. (HEAD -> master)
+* def5678 - (1 day ago) Fix CSS tema - Danilo M.
+|\
+| * ghi9012 - (2 days ago) WIP: nuova funzione - Danilo M. (content/bozza)
+|/
+* jkl3456 - (5 days ago) Bump submodule tema - Danilo M. (origin/master)
+```
+
+Molto meglio del semplice `git log`.
+
+### sw: Abbreviazione per switch
+
+```ini
+[alias]
+ sw = switch
+```
+
+`git sw main` è più veloce da digitare di `git switch main`, e `git sw -c feature/nuovo` crea e passa in un solo comando.
+
+## Una Giornata Tipo
+
+Ecco come queste impostazioni lavorano insieme nella pratica.
+
+Mattina: sincronizzo con il repository. `git fetch` parte silenziosamente, `fetch.prune` e `prunetags` puliscono branch cancellati e tag vecchi senza che ci pensi.
+
+Inizio l'articolo della settimana per il sito Hugo. Creo un nuovo branch di contenuto:
+
+```bash
+git sw -c content/git-config-in-profondita
+```
+
+Niente `--set-upstream` dopo. `push.autoSetupRemote` ci pensa lui.
+
+Scrivo, committo. Il commit viene firmato con GPG automaticamente. Nessun passaggio extra.
+
+```bash
+git commit -m "Aggiungo prima bozza articolo git config"
+```
+
+Push quando ho finito:
+
+```bash
+git push
+```
+
+Nessun errore di upstream. Funziona e basta.
+
+Più tardi, il branch main riceve un aggiornamento del submodule del tema. Ribaso il mio lavoro sopra:
+
+```bash
+git fetch
+git rebase main
+```
+
+C'è un conflitto nel puntatore del submodule, il repository del tema è andato avanti. `merge.conflictstyle = zdiff3` mi mostra esattamente cosa è cambiato. Lo risolvo una volta.
+
+Più tardi, un secondo branch ha lo stesso conflitto del submodule. `rerere` ricorda la mia risoluzione e la applica automaticamente con `rerere.autoupdate`. Nessuna ri-risoluzione.
+
+Prima di unire su main, controllo il grafo:
+
+```bash
+git lg
+```
+
+L'output ordinato mostra la timeline chiaramente.
+
+Merge su main:
+
+```bash
+git switch main
+git merge content/git-config-in-profondita
+```
+
+Se c'è un conflitto qui (improbabile dato che abbiamo ribassato), `zdiff3` mostra il contesto dell'antenato.
+
+Fatto. Tutte le impostazioni hanno lavorato insieme in modo trasparente.
+
+## La Configurazione Completa
+
+Ecco il blocco completo così come sta nel mio `~/.gitconfig`:
+
+```ini
+[user]
+ name = Danilo M.
+ email = danix@danix.xyz
+ signingkey = IL_TUO_KEY_ID_QUI
+
+[pull]
+ rebase = true
+
+[push]
+ autoSetupRemote = true
+
+[commit]
+ gpgsign = true
+
+[help]
+ autocorrect = 10
+
+[fetch]
+ prune = true
+ prunetags = true
+
+[merge]
+ conflictstyle = zdiff3
+
+[rerere]
+ enabled = true
+ autoupdate = true
+
+[branch]
+ sort = -committerdate
+
+[column]
+ ui = auto
+
+[log]
+ abbrevCommit = true
+ follow = true
+
+[diff]
+ mnemonicPrefix = true
+ renames = true
+ wordRegex = [^[:space:]]
+
+[alias]
+ lg = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all
+ sw = switch
+```
+
+Prendi quello che ti serve. Lascia quello che non si adatta al tuo flusso di lavoro.
+
+## Una Configurazione che Evolve
+
+Questa non è la configurazione git "corretta", è quella che si adatta a come lavoro io. La sto raffinando da anni e continuerà a evolversi man mano che trovo nuovi punti di attrito e scopro nuove impostazioni. L'obiettivo non è seguire la mia configurazione alla lettera, ma pensare a cosa ti rallenta e cercare l'impostazione git che lo risolve.
+
+Se usi qualcuna di queste impostazioni, o se ne hai trovate altre che hanno cambiato il tuo flusso di lavoro, fammelo sapere nei commenti. Sono sempre curioso di sapere come gli altri configurano i loro strumenti.
