«Copio la cartella in progetto_v2_FINALE_vero.zip»
Una sola cartella con tutta la cronologia dentro. Ogni versione è un commit etichettato.
Un corso completo in un'unica pagina: entri senza sapere nulla di Git ed esci sapendolo usare. Prima capisci perché esiste e i concetti chiave, poi provi i comandi veri in un terminale simulato con un grafo che cresce a ogni comando, infine vedi come funziona nel mondo reale con i file e GitHub. Nessuna installazione: tutto qui dentro.
Git è un sistema di controllo di versione: tiene la cronologia completa di un progetto, così puoi tornare indietro, lavorare in parallelo e collaborare senza pestarti i piedi. Immagina un videogioco in cui ogni salvataggio è permanente e puoi sempre ricaricarlo.
«Copio la cartella in progetto_v2_FINALE_vero.zip»
Una sola cartella con tutta la cronologia dentro. Ogni versione è un commit etichettato.
«Ho rotto tutto e non so cosa ho cambiato ieri»
Vedi esattamente cosa è cambiato e quando, e torni indietro a qualunque versione in un comando.
«Provo una modifica rischiosa… ma se non funziona?»
Apri un ramo separato, sperimenti in tranquillità e lo unisci solo se funziona.
«In due sullo stesso file ci mandiamo versioni via email»
Ognuno lavora sulla sua copia e Git unisce i contributi. È lo standard per lavorare in gruppo.
Git lavora in locale, sul tuo computer. GitHub (o GitLab) è un servizio online dove caricare una copia del repository per condividerlo e salvarlo nel cloud — ne parliamo alla fine. Non sono la stessa cosa: Git è lo strumento, GitHub è un posto dove mettere i tuoi repository.
Sei parole che sentirai sempre. Ti bastano per capire tutto il resto — e nel banco di prova qui sotto le vedrai muoversi.
La cartella del progetto più la sua cronologia. «Repo» per gli amici. La crei con git init.
Una fotografia salvata del progetto in un momento preciso, con un messaggio che la descrive. È il mattone di Git.
Una linea di sviluppo parallela. Il ramo di default si chiama main. Ne apri altri per lavorare senza rischi.
Un segnalibro: dove stai lavorando adesso. Di solito punta alla punta del ramo corrente.
Unire due rami. Git combina il lavoro; se le linee erano divergenti crea un «commit di merge».
Una copia del repo online. push carica i tuoi commit, pull scarica quelli degli altri.
Un Git vero in miniatura. Scrivi i comandi a sinistra e guarda il grafo dei commit crescere a destra: i commit sono cerchi, i rami etichette colorate, HEAD il cerchio col contorno tratteggiato. Nessun file reale, così puoi sbagliare senza conseguenze. Nella lezione guidata qui sotto ti diciamo cosa scrivere, passo per passo.
Segui i passi in ordine. Premi ▸ Esegui su ciascuno: il comando parte nel terminale qui sopra e il grafo si aggiorna. Leggi la spiegazione, osserva il grafo, poi passa al successivo. Alla fine avrai creato commit, un ramo e la tua prima fusione.
↺ Reset nel terminale per ripartire da zero, poi scorri in alto per guardare il grafo mentre esegui ogni passo.
git init trasforma una cartella normale in un repository Git. Nasce già il ramo main, ancora «vuoto»: punterà a qualcosa solo dopo il primo commit.
Salvi la prima «fotografia». Il -m è il messaggio che descrive il salvataggio. Nel grafo appare il primo cerchio, con l'etichetta main sopra.
Un altro salvataggio sopra il precedente. Ora hai una cronologia: due commit collegati, e main che avanza sul più recente insieme a HEAD.
git log elenca i commit dal più recente. Vedi gli identificatori, i messaggi e dove puntano HEAD e main.
git checkout -b feature crea il ramo feature e ci sposta HEAD sopra. Da qui lavori in parallelo senza toccare main.
Un commit mentre sei su feature: avanza solo questo ramo. Il grafo si biforca — main resta fermo, feature va avanti.
git checkout main riporta HEAD sul ramo principale. Il lavoro su feature non è perso: è lì, su un'altra linea, che ti aspetta.
git merge feature porta dentro main quello che hai fatto su feature. Le due linee si riuniscono: è il cuore del lavoro in gruppo.
🎉 Fatto. Hai appena usato il flusso che si ripete ogni giorno su progetti reali: salvare commit, ramificare per lavorare in sicurezza, unire. Prova a rifarlo da solo scrivendo i comandi a mano, o usa ✦ Carica esempio per vedere uno scenario più ricco.
Nel banco di prova i file non esistono, per concentrarci sul grafo. Su Git vero, invece, un commit nasce dai file. Ecco l'unico pezzo che manca — ed è semplice.
I tuoi file, come li stai modificando adesso sul disco.
git add→La «lista di cosa entrerà nel prossimo commit». Scegli tu cosa salvare.
git commit→Il commit è salvato per sempre nella cronologia locale.
git push→La copia online, condivisa con tutti e salvata nel cloud.
git status
Mostra quali file hai modificato e quali sono già in staging. È il comando che userai di più: ti dice sempre «a che punto sei».
git add file.txt
Mette file.txt in staging. git add . aggiunge tutto. È il passo che scegli prima di ogni commit.
git commit -m "..."
Salva nel repository solo ciò che è in staging, con un messaggio. Esattamente i commit che hai creato nel banco di prova.
git clone <url>
Scarica un repository esistente da GitHub sul tuo computer, cronologia compresa. È come inizi a lavorare su un progetto altrui.
git push
Carica i tuoi commit locali su GitHub, così gli altri li vedono e il lavoro è al sicuro online.
git pull
Scarica e unisce i commit che gli altri hanno caricato. Da fare spesso, per restare allineato col gruppo.
.gitignore
Un file che elenca ciò che Git deve ignorare (file temporanei, password, cartelle enormi). Non tutto va versionato.
git diff
Mostra riga per riga cosa è cambiato rispetto all'ultimo commit. Utile per ricontrollare prima di salvare.
git add→git commit -m "..."→git push↺
Sintassi, descrizione, opzioni ed esempi per ogni comando del sandbox. Premi inserisci accanto a un esempio per scriverlo nel terminale e provarlo.
Nessun comando corrisponde alla ricerca.