Tutorial Git: i comandi di base (add, commit, push, pull)

Cinque comandi bastano per lavorare tutti i giorni: status, add, commit, push e pull. Questo capitolo li prende uno per uno, poi affronta quello che nessun tutorial dovrebbe saltare: come tornare indietro quando hai sbagliato.

Una condizione preliminare: la tua identità deve essere dichiarata, altrimenti Git rifiuterà il tuo primo commit. Se non l’hai ancora fatto, torna al capitolo sull’installazione.

Le tre zone di Git

Tutto diventa più semplice quando hai capito che i tuoi file si trovano in una di tre zone.

• La directory di lavoro: i tuoi file così come li vedi nel gestore di file.
• L’indice, chiamato anche staging area: l’elenco di ciò che finirà nel prossimo commit. git add ci deposita le modifiche.
• Il repository: la cronologia dei commit, quella che git commit alimenta.

All’inizio questa zona intermedia spiazza, ma è proprio lei a permetterti di registrare tre modifiche su cinque e tenere le altre due per un commit separato.

git status, il comando da digitare in continuazione

Ti dice a che punto sei, e i suoi messaggi contengono quasi sempre il comando da digitare dopo. Prendi l’abitudine di lanciarlo prima e dopo ogni operazione.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	.env
	app.js
	node_modules/

nothing added to commit but untracked files present (use "git add" to track)

La versione breve occupa una riga per file e diventa in fretta un riflesso:

git status --short

?? .env
?? app.js
?? node_modules/

?? segnala un file che Git non traccia ancora, A un file aggiunto all’indice, M un file modificato.

.gitignore: quello che non deve mai partire

Prima ancora del primo git add, metti da parte ciò che non ha niente a che fare con un repository: le dipendenze reinstallabili, i file di configurazione che contengono dei segreti, i file generati dal sistema o dall’editor.

Crea un file .gitignore nella radice del progetto:

node_modules/
vendor/
.env
.env.local
dist/
build/
*.log
.DS_Store
.idea/
.vscode/

Rilancia git status: i file ignorati sono spariti dall’elenco.

?? .gitignore
?? app.js

Il .gitignore, invece, è versionato: fa parte del progetto e va condiviso con il team.

Attenzione a una trappola: .gitignore non ha alcun effetto su un file già tracciato. Se hai committato un .env prima di pensarci, devi toglierlo esplicitamente dall’indice:

git rm --cached .env
git commit -m "Retire le fichier .env du suivi"

L’opzione --cached è essenziale: toglie il file dall’indice senza cancellarlo dal disco.

E considera compromessi i segreti che conteneva: restano leggibili nella cronologia. Cambiali.

git add: preparare il commit

git add app.js          # un file
git add src/            # un'intera cartella
git add .               # tutto ciò che è cambiato sotto la cartella corrente
git add -p              # scegliere pezzo per pezzo, in modo interattivo

git add -p merita di essere provato presto. Git ti mostra ogni blocco di modifiche e ti chiede se lo vuoi nel commit. È il modo più semplice per produrre commit che raccontano una cosa sola.

git commit: registrare

git commit -m "Ajoute la page d'accueil"

[main (root-commit) fd4fdb7] Ajoute la page d accueil
 2 files changed, 3 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 app.js

Se l’indice è vuoto, Git non crea niente e te lo dice:

On branch main

Initial commit

nothing to commit (create/copy files and use "git add" to track)

Sui messaggi di commit vale la pena ricordare una sola regola: scrivi che cosa fa il commit, non che cosa hai toccato. «Corregge il calcolo dell’IVA sugli ordini fuori UE» vale più di «modif facture.php». Stai scrivendo per te stesso fra sei mesi.

La scorciatoia -am combina add e commit, ma solo per i file già tracciati:

git commit -am "Corrige le libellé du bouton"

Leggere la cronologia

git log                                  # completo
git log --oneline                        # una riga per commit
git log --oneline --graph --decorate     # con la forma dei branch
git log -p app.js                        # la cronologia di un solo file, con i diff

* fd4fdb7 (HEAD -> main) Ajoute la page d accueil

HEAD indica il punto della cronologia in cui ti trovi. La freccia mostra che HEAD segue il branch main.

Vedere le proprie modifiche prima di committare

Due comandi, spesso confusi, che guardano due zone diverse.

git diff            # ciò che è cambiato ma non è ancora nell'indice
git diff --staged   # ciò che è nell'indice e partirà al prossimo commit

diff --git a/app.js b/app.js
index e921523..ebde020 100644
--- a/app.js
+++ b/app.js
@@ -1 +1 @@
-console.log('hello');
+console.log('bonjour');

Dopo un git add app.js, la stessa modifica cambia lato: git diff non restituisce più niente e git diff --staged mostra il blocco. È il modo migliore per farsi un’idea concreta dell’indice.

git push e git pull: scambiare con il server

git push        # inviare i commit locali
git pull        # recuperare e integrare quelli degli altri

Queste due forme brevi funzionano solo se il branch ha un collegamento verso il server, creato dal -u del capitolo precedente. Per verificare il collegamento:

git branch -vv

* feature/panier bc2203a Page d accueil
  main           bc2203a [origin/main] Page d accueil

Il branch main segue origin/main, il branch feature/panier per ora non segue niente.

Se qualcuno ha pushato mentre lavoravi, il tuo push viene rifiutato. La procedura da seguire e la spiegazione completa sono nel capitolo sui branch.

Annullare una sciocchezza

È la parte che i principianti cercano più spesso, e quella che viene spiegata di meno. Il riflesso giusto è rispondere prima a una domanda: quello che voglio annullare è già finito sul server?

Il file è modificato, voglio tornare all’ultimo commit

git restore app.js       # un file
git restore .            # tutta la directory di lavoro

Attenzione, questo comando distrugge le tue modifiche senza rete: non sono mai state registrate da nessuna parte, Git non può recuperarle.

Ho fatto git add troppo in fretta

git restore --staged app.js

Il file esce dall’indice, le tue modifiche restano intatte nella directory di lavoro.

Questi due comandi sono l’equivalente moderno di git checkout -- fichier e git reset HEAD fichier. git restore esiste da Git 2.23 e dice chiaramente che cosa fa, mentre checkout e reset fanno ciascuno tre cose diverse a seconda delle opzioni.

Il messaggio del mio ultimo commit è sbagliato

git commit --amend -m "Le bon message"

Lo stesso comando serve ad aggiungere un file dimenticato: fai il tuo git add, poi rilancia git commit --amend. Usalo solo su un commit non ancora pushato: --amend non modifica il commit, ne crea uno nuovo al suo posto, e il vecchio identificatore sparisce.

Il commit è già pushato, voglio disfarlo in modo pulito

git revert HEAD

[main 0246de1] Revert "Ajoute un fichier par erreur"
 1 file changed, 1 deletion(-)
 delete mode 100644 bug.txt

git revert crea un nuovo commit che applica l’inverso del precedente. La cronologia si allunga invece di essere riscritta, ed è esattamente ciò che serve quando altre persone hanno già recuperato il tuo lavoro. È l’unico metodo senza rischi su un branch condiviso.

Il commit non è pushato, voglio eliminarlo

git reset --soft HEAD~1   # disfa il commit, tiene tutto nell'indice
git reset --mixed HEAD~1  # disfa il commit, tiene i file modificati (comportamento predefinito)
git reset --hard HEAD~1   # disfa il commit ed elimina le modifiche

--soft è il più utile: ti restituisce le modifiche pronte per essere ricommittate in un altro modo. --hard è l’unico che distrugge del lavoro, e non avvisa. Digitalo solo se sei sicuro.

Ho fatto un reset –hard di troppo

Non è tutto perduto. Git conserva per diverse settimane la traccia di tutti gli stati per cui HEAD è passato:

git reflog

8207e54 HEAD@{0}: reset: moving to HEAD~2
f3951da HEAD@{1}: commit: Version 3
8ac671c HEAD@{2}: commit: Version 2
8207e54 HEAD@{3}: commit (initial): Version 1

I due commit cancellati sono ancora lì. Individua la riga che corrisponde allo stato che ti serve, annota il suo identificatore e tornaci:

git reset --hard f3951da

Il reflog, però, recupera solo ciò che era stato committato. Le modifiche mai registrate sono perse per sempre, il che è un motivo in più per committare spesso.

Il riepilogo

Ora sai lavorare da solo. Il capitolo successivo aggiunge gli altri: branch, merge e conflitti. L’ultimo capitolo affronterà poi l’organizzazione di questi branch su scala di team.