Tutorial Git: installare e configurare Git su Windows, macOS e Linux

Questo capitolo installa Git, imposta i tre parametri senza i quali il tuo primo commit verrà rifiutato e configura l’autenticazione con GitHub o GitLab. Mettine in conto una quindicina di minuti, parte SSH compresa.

Se arrivi direttamente qui, la differenza tra Git e GitHub e il dettaglio del percorso sono spiegati nell’introduzione del tutorial.

Installare Git

Se lavori su macOS o Linux, Git è probabilmente già sulla tua macchina. Verifica prima di installare qualsiasi cosa:

git --version

Se il comando risponde con un numero di versione, Git è installato e puoi passare alla configurazione. Se risponde che il comando non esiste, segui la sezione del tuo sistema.

Windows

La via più semplice è il gestore di pacchetti integrato in Windows:

winget install --id Git.Git -e --source winget

In alternativa scarica l’installer da git-scm.com/install/windows e lascia le opzioni predefinite. L’ultima versione pubblicata al momento di questa verifica è Git for Windows 2.55.0(5), del 20 agosto 2026. L’installazione porta con sé Git Bash, un terminale che riproduce l’ambiente Unix. Usalo al posto del prompt dei comandi: tutti i comandi di questo tutorial ci funzionano così come sono.

macOS

Git arriva con gli strumenti a riga di comando di Xcode. Al primo richiamo di git il sistema propone di installarli, oppure puoi forzare l’installazione:

xcode-select --install

Questa versione è affidabile, ma spesso è indietro di qualche mese rispetto a quella ufficiale. Per restare aggiornato passa da Homebrew:

brew install git

Linux

Usa il gestore di pacchetti della tua distribuzione.

# Debian, Ubuntu e derivate
sudo apt update && sudo apt install git

# Fedora, RHEL, Rocky
sudo dnf install git

# Arch
sudo pacman -S git

# Alpine
sudo apk add git

La versione installata dipende dalla vostra distribuzione, e lo scarto a volte è importante. Le versioni rilevate il 7 settembre 2026 sono riportate nella sezione « Risultato misurato » in fondo a questo capitolo. Ubuntu 24.04 fornisce Git 2.43, uscito a fine 2023: è più che sufficiente per tutto ciò che fa questo tutorial, poiché i comandi più recenti che usiamo risalgono a Git 2.23.

Dichiarare chi sei: nome e indirizzo e-mail

Git scrive l’autore di ogni commit nella cronologia. Finché non gli dici chi sei, si rifiuta di registrare qualsiasi cosa:

Author identity unknown

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'root@23d1d26b6831.(none)')

Imposta quindi i due valori prima di ogni altra cosa:

git config --global user.name "Damien Flandrin"
git config --global user.email "dam@example.com"

L’opzione --global scrive nel tuo file personale e vale per tutti i progetti. Senza, l’impostazione riguarda solo il repository corrente: comodo quando usi un indirizzo di lavoro su certi progetti e uno personale su altri.

Usa un indirizzo che accetti di rendere pubblico: compare nella cronologia, e la cronologia viene distribuita a chiunque cloni il progetto. Se preferisci non esporre il tuo, GitHub mette a disposizione un indirizzo sostitutivo in @users.noreply.github.com.

Scegliere il nome del branch predefinito

È il punto su cui circolano più informazioni sbagliate. Si legge spesso che ormai Git crea un branch main. Non è vero. Ecco cosa produce git init con Git 2.55, la versione corrente a settembre 2026:

hint: Using 'master' as the name for the initial branch. This default branch name
hint: will change to "main" in Git 3.0. To configure the initial branch name
hint: to use in all of your new repositories, which will suppress this warning,
hint: call:
hint:
hint: 	git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: 	git branch -m <name>
hint:
hint: Disable this message with "git config set advice.defaultBranchName false"
Initialized empty Git repository in /root/a1/.git/

Il branch si chiama quindi proprio master, ed è Git stesso ad annunciare che il valore predefinito passerà a main dalla versione 3.0. A cambiare sono state le piattaforme: GitHub crea i nuovi repository con un branch main da ottobre 2020, GitLab dalla versione 14. Da qui lo scarto permanente tra quello che fa la tua macchina e quello che fa il server.

Chiudi la questione una volta per tutte:

git config --global init.defaultBranch main

Il messaggio sparisce e i repository creati da lì in poi partono su main. Attenzione: l’impostazione vale solo per i nuovi repository. Per un repository che esiste già e il cui branch si chiama master:

git branch -m master main

Verificare la configurazione

Tre comandi bastano a sapere a che punto sei:

git config --global --list                # cosa è impostato
git config --global --list --show-origin  # e in quale file
git config --global --edit                # aprire il file

La configurazione personale è un semplice file di testo, ~/.gitconfig, che puoi leggere e modificare direttamente:

[user]
	name = Damien Flandrin
	email = dam@example.com
[init]
	defaultBranch = main

Vale la pena sistemare subito altre due cose. L’editor che Git usa per i messaggi di commit, altrimenti prima o poi finisci dentro Vim senza sapere come uscirne:

git config --global core.editor "code --wait"   # Visual Studio Code
git config --global core.editor "nano"          # o qualsiasi editor da terminale

E il comportamento di git pull, che vedremo in dettaglio nel capitolo sui branch:

git config --global pull.rebase true

Autenticarsi su GitHub o GitLab

Qui serve una precisazione, perché su questo punto i principianti perdono un sacco di tempo. La tua password GitHub non serve più a niente per Git. GitHub ha smesso di accettare le password dell’account per le operazioni Git il 13 agosto 2021. Ecco cosa risponde il server se ci provi lo stesso:

Cloning into 'depot-prive'...
remote: Invalid username or token. Password authentication is not supported for Git operations.
fatal: Authentication failed for 'https://github.com/damienflandrin/depot-prive.git/'

Restano due metodi validi: la chiave SSH o il personal access token. La chiave SSH richiede cinque minuti di configurazione e poi non te la chiede più nessuno. È quella che consigliamo.

Creare una chiave SSH

ssh-keygen -t ed25519 -C "dam@example.com"

Conferma il percorso proposto. La passphrase è facoltativa ma consigliata: protegge la chiave se la tua macchina viene compromessa.

Generating public/private ed25519 key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:s5YjDRbNgv3/o8SvEFh4A6hzpWddSsquX0l0k4aUptw dam@example.com

Sono stati creati due file. id_ed25519 è la chiave privata: non lascia mai la tua macchina, non si copia da nessuna parte, non si incolla in nessun modulo. id_ed25519.pub è la chiave pubblica, quella che affidi al server.

Mostra la chiave pubblica e copia la riga intera:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINjiBkboRdOPXk2UWn3UUMSv2qr8G9cGvzKsTd+ZyYCa dam@example.com

Incollala poi in Settings > SSH and GPG keys > New SSH key su GitHub, oppure in Preferenze > Chiavi SSH su GitLab.

Verificare che la chiave funzioni

ssh -T git@github.com

Alla prima connessione ti viene chiesto di confermare l’impronta del server. Quella di GitHub per le chiavi Ed25519 è SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU: confrontala con quella pubblicata da GitHub prima di rispondere yes. Se è tutto a posto, GitHub risponde con un messaggio di benvenuto che riporta il tuo nome utente e precisa che l’accesso alla shell non è consentito, il che è normale. Se invece ottieni:

git@github.com: Permission denied (publickey).

vuol dire che la chiave pubblica non è stata registrata sul tuo account, oppure che hai incollato per errore la chiave privata.

L’alternativa: il personal access token

Se SSH è bloccato sulla tua rete, o se ti serve dentro uno script di integrazione continua, usa un personal access token. Su GitHub lo crei in Settings > Developer settings > Personal access tokens, preferendo i token a portata ristretta (fine-grained), che limitano l’accesso a un repository preciso e scadono da soli. Su GitLab l’equivalente si trova in Preferenze > Token di accesso.

Il token si usa al posto della password quando Git la chiede. Per non riscriverlo a ogni comando, attiva un credential helper:

git config --global credential.helper store    # semplice, ma il token è scritto in chiaro
git config --global credential.helper osxkeychain  # macOS, salvataggio nel portachiavi

Su Windows, Git Credential Manager è installato e attivo per impostazione predefinita insieme a Git for Windows.

Tratta un token esattamente come una password: non finisce in un repository, non in un file di configurazione versionato, non in un URL che condividi.

La tua postazione è pronta. Il capitolo successivo crea un repository su GitHub o GitLab e lo collega a una cartella della tua macchina.

Risultato misurato

Versione di Git installata dal gestore di pacchetti sull’immagine ufficiale di ogni distribuzione, rilevata il 7 settembre 2026:

Vanno tutte bene: il comando più recente usato in questo tutorial, git switch, risale a Git 2.23.