Trasformi una cartella qualsiasi in un repository Git, partendo da zero.
clone parte da un progetto che esiste già; init lo crea dal nulla sul tuo computer.
Non sei un dev? Non importa. Ogni comando ha una card animata: guardi cosa si muove e capisci al volo cosa fa — Pull Request compresa, quella che manda in crisi pure i programmatori veri.
Il giro che fai ogni giorno: dal codice sul tuo PC fino a GitHub e ritorno.
Trasformi una cartella qualsiasi in un repository Git, partendo da zero.
clone parte da un progetto che esiste già; init lo crea dal nulla sul tuo computer.
Scarichi l’intera copia di un progetto da GitHub al tuo computer. È il punto di partenza di tutto.
Scegli quali modifiche far entrare nel prossimo salvataggio, spostandole nell’area di staging.
Staging ≠ salvataggio. Stai solo preparando la lista di ciò che verrà incluso nel commit.
Salvi le modifiche selezionate nella storia del progetto, con un messaggio che spiega cosa hai fatto.
Il commit resta sul tuo computer. Finché non fai push, nessun altro lo vede.
Spingi i tuoi commit locali su GitHub: ora il lavoro è online, al sicuro e visibile agli altri.
Tiri giù le modifiche che altri hanno messo su GitHub e le integri nel tuo lavoro locale.
Occhio: git pull ≠ Pull Request. Stesso nome, concetti diversi (la PR è più in basso).
Scarichi le novità da GitHub ma NON le fondi nel tuo lavoro: le tieni da parte per guardarle prima.
pull = fetch + merge. fetch è la versione prudente: prima scarichi, poi decidi.
Comandi innocui che ti dicono a che punto sei. Quelli che digiti di continuo per non perderti.
Ti dice a che punto sei: quali file hai cambiato, cosa è già in staging, cosa manca. Lo userai di continuo.
È del tutto innocuo: non cambia niente. Nel dubbio, git status.
Mostra la storia dei commit: chi ha fatto cosa e quando. È la memoria del progetto.
Linee di lavoro parallele per sperimentare senza rompere il ramo principale.
Crei una linea di lavoro parallela che parte dal punto in cui sei: sperimenti senza toccare main.
Un ramo costa zero. È solo un’etichetta che punta a un commit: puoi averne quanti vuoi, in parallelo.
Ti sposti da un ramo all’altro. HEAD indica “dove sei ora”, cioè dove finiranno i prossimi commit.
Un tempo si usava git checkout; oggi git switch fa la stessa cosa in modo più chiaro.
Unisci il lavoro di un ramo dentro un altro: le due linee tornano una sola.
Se le stesse righe sono cambiate su entrambi i rami, git chiede a te come combinarle: è il conflitto di merge.
Come proporre modifiche a un progetto che non è tuo, senza permessi di scrittura.
Crei una tua copia di un progetto altrui, sul tuo account GitHub, dove puoi fare tutto quello che vuoi.
Non è un comando git. È un pulsante sul sito di GitHub: serve proprio quando il progetto non è tuo.
Dài un nome ai repository remoti: “origin” è la tua copia, “upstream” è il progetto originale.
Fai push su origin, prendi le novità da upstream.
Dal tuo ramo su GitHub apri una proposta di modifica verso il progetto originale. Il maintainer la esamina e, se gli piace, la unisce.
Il trucco: sembra una push, ma è il contrario — tu chiedi, non scrivi. Si chiama pull request perché è il maintainer a “tirare dentro” (pull) il tuo lavoro.
Continua a esplorare
Guide, corsi e strumenti scelti per te — a partire da questa pagina.
Un brief vago diventa un’app navigabile.
Deploy su Vercel senza tecnicismi: dal progetto che hai su GitHub a un link online che puoi mandare a chiunque, e poi il tuo dominio personale sopra.
Il foglio da portare in call
Claude guarda i tuoi video e li trasforma in testo.
Metti su GitHub il progetto fatto con Claude Code o Codex, torna indietro quando si rompe e fatti aiutare: Git spiegato per chi non è programmatore.
Skill AI per designer