Modulo 04 — Basi di Git

Il repository

Un repo (repository) è l’area di lavoro in cui Git traccia e gestisce i file di una cartella. Ogni volta che vuoi usare Git con un progetto devi creare un repository; sul tuo computer puoi averne quanti ne vuoi, ognuno con storia e contenuti indipendenti (il sito del portfolio, l’idea di startup, la sceneggiatura, l’app clone di Reddit…).

Committare: la feature più importante

Un commit è come un salvataggio in un videogioco: uno snapshot dello stato del repository in un dato momento.

Differenza con il “salva” di un editor: lì salvi lo stato di un singolo file; con Git salvi lo stato di più file e cartelle insieme.

Esempio: in una mattinata modifichi 7 file (elimini team.html, modifichi about.html e about.css, crei navbar, logo…). Con i commit puoi raggruppare quelle modifiche in blocchi logici, es. “aggiunta navbar” e “nuovi membri nella pagina about”.

Il workflow base

Lavora sui file  →  git add  →  git commit
(crea/modifica/     (raggruppa le    (salva tutto ciò che
 elimina file)      modifiche da     era in staging)
                    salvare)

Tre fasi: Working Directory → (git add) → Staging Area → (git commit) → Repository.

Le tre aree: la working directory (i tuoi file), la staging area (dove raccogli le modifiche con git add) e il repository (la history, dove finiscono i commit).

git status

Primo comando utile: informa sullo stato del repository. Se lo esegui fuori da un repo:

git status
# fatal: not a git repository (or any of the parent directories)

git init — creare il repository

git init

Crea un repo nella cartella corrente. Da fare una volta per progetto, nella cartella di primo livello del progetto.

⚠️ Git traccia la directory e tutte le sottodirectory annidate: non inizializzare mai un repo dentro un altro repo! Prima di git init, esegui git status per assicurarti di non essere già dentro un repository.

Se per sbaglio crei un repo dentro un repo: elimina la cartella nascosta .git e il repository scompare.

”Git ci sta guardando”

Dopo git init, crea un file e ri-esegui git status: Git segnala il nuovo file come untracked — lo vede ma non lo sta ancora tracciando.

Ciclo di vita dei file: un file passa da untracked (o modified) a staged con git add, da staged a unmodified col commit — e così via a ogni ciclo di modifiche.

git add — mettere in staging

Serve a dire a Git “includi questa modifica nel prossimo commit”:

git add file1 file2   # file specifici (separati da spazi)
git add .             # tutte le modifiche della directory corrente

Lo staging è utile proprio per scegliere cosa raggruppare in un commit: puoi fare add di alcuni file, committare, poi add degli altri e fare un secondo commit — così ogni commit resta coerente e descrittivo.

git commit — salvare lo snapshot

git commit            # committa lo staging e apre un editor per il messaggio
git commit -m "messaggio"   # messaggio inline, senza editor

Il -m evita l’editor di testo: all’inizio è la strada più comoda. Il messaggio deve riassumere le modifiche incluse nel commit.

git status è tuo amico

Usalo di continuo per verificare cosa è in staging e cosa no: è il modo più economico per non sbagliare cosa finisce in un commit.

---

Immagini: documentazione ufficiale di Git (git-scm.com, dal libro Pro Git di Scott Chacon), licenza CC BY-NC-SA 3.0.