Il tutorial completo per imparare il versionamento del codice da zero: commit, branch, merge, pull request, conflitti, GitHub Pages e molto altro.
Introduzione a Git
Git è il sistema di controllo di versione (version control) più usato al mondo. Tiene traccia di ogni modifica al tuo codice, ti permette di tornare a versioni precedenti, di lavorare su più funzionalità in parallelo e di collaborare con altri sviluppatori senza sovrascrivervi il lavoro a vicenda.
È stato creato nel 2005 da Linus Torvalds (il creatore di Linux) ed è oggi lo standard assoluto: ogni azienda di software lo usa, e saperlo usare è un requisito per qualsiasi lavoro da sviluppatore.
Cosa fa Git per te
📜 Storia completa: ogni versione del progetto è salvata e recuperabile
🌿 Branch: sviluppi nuove funzionalità in parallelo senza toccare il codice stabile
🤝 Collaborazione: più persone lavorano sullo stesso progetto senza caos
⏪ Annullare errori: torni indietro a qualsiasi punto della storia
💾 Backup distribuito: ogni copia del repository contiene tutta la storia
Git e GitHub non sono la stessa cosa
Git è il programma che gira sul tuo computer. GitHub è un servizio online che ospita i repository Git e aggiunge collaborazione, pull request, issue e molto altro. Esistono alternative a GitHub (GitLab, Bitbucket), ma Git è sempre lo stesso.
📘 Questo sito che stai leggendo è ospitato proprio su GitHub Pages: imparerai a pubblicare il tuo sito allo stesso modo nella sezione GitHub.
Il flusso di lavoro Git in 4 comandi
Installare Git
Git è gratuito e disponibile per Windows, macOS e Linux. Scaricalo da git-scm.com.
Installazione per sistema operativo
💡 Su Windows usa Git Bash (installato insieme a Git): ti dà gli stessi comandi di Linux/Mac e tutti i tutorial funzioneranno identici.
Configurare Git
Prima del primo commit devi dire a Git chi sei: nome ed email vengono registrati in ogni commit che fai. La configurazione si gestisce con git config.
Configurazione iniziale
📘 --global applica la configurazione a tutti i tuoi repository. Senza, vale solo per il repository corrente: utile se in un progetto usi un'email di lavoro diversa.
Get Started — il primo repository
Un repository (o "repo") è la cartella del tuo progetto sotto il controllo di Git. Si crea con git init, che aggiunge una sottocartella nascosta .git dove Git salva tutta la storia.
Creare il primo repository
Le tre aree di Git
Area
Cosa contiene
Working directory
I file su cui stai lavorando
Staging area
Le modifiche pronte per il prossimo commit
Repository
La storia dei commit salvata in .git
💡 Pensa alla staging area come al "carrello della spesa": ci metti dentro le modifiche che vuoi, poi con il commit "paghi" e le rendi definitive.
Aggiungere nuovi file
Quando crei un file in un repository, Git lo vede ma non lo traccia automaticamente: è untracked. Devi dirgli esplicitamente di seguirlo con git add.
Tracciare nuovi file
Stato del file
Significato
Untracked
Nuovo, Git non lo segue ancora
Modified
Tracciato e modificato, ma non in staging
Staged
Pronto per il prossimo commit
Committed
Salvato nella storia del repository
La Staging Area
La staging area (o "index") è lo spazio intermedio dove prepari il prossimo commit. Ti permette di scegliere esattamente quali modifiche includere, anche solo alcuni file tra i tanti modificati.
Gestire la staging area
💡 Commit piccoli e mirati sono più facili da capire e da annullare. La staging area serve proprio a questo: separare modifiche diverse in commit diversi.
Il Commit
Il commit è una fotografia del progetto in un preciso momento, salvata per sempre nella storia. Ogni commit ha un identificatore univoco (hash SHA), un autore, una data e un messaggio che descrive la modifica.
Creare commit
Scrivere buoni messaggi di commit
✅ Aggiunge la validazione email al form di registrazione
✅ Corregge il crash al login con password vuota
❌ fix, modifiche, aggiornamento vario
📘 Convenzione diffusa: messaggio al presente indicativo, prima riga sotto i 50-70 caratteri, descrizione di cosa e perché (il come si vede già dal codice).
I Tag
I tag sono etichette permanenti su commit specifici, usate tipicamente per marcare le versioni rilasciate del software (v1.0.0, v2.1.3...).
Creare e gestire i tag
💡 I tag seguono di solito il versionamento semantico: MAJOR.MINOR.PATCH (es. 2.4.1) — major per modifiche incompatibili, minor per nuove funzionalità, patch per correzioni.
Git Stash
git stash mette da parte temporaneamente le modifiche non committate, lasciando la working directory pulita. Perfetto quando devi cambiare branch al volo ma il lavoro non è pronto per un commit.
Accantonare e recuperare modifiche
⚠️ Lo stash è pensato per parcheggi brevi. Per lavoro che dura giorni, crea un branch: gli stash dimenticati sono una causa classica di lavoro perso.
Esplorare la storia
git log e i comandi collegati ti permettono di esplorare l'intera storia del progetto: chi ha cambiato cosa, quando e perché.
Interrogare la storia
💡 git log --oneline --graph --all è il comando da memorizzare: ti mostra la struttura dei branch ad albero direttamente nel terminale.
Ottenere aiuto
Git ha una documentazione integrata completa per ogni comando, consultabile direttamente dal terminale.
Un branch (ramo) è una linea di sviluppo indipendente. Il branch principale si chiama main; per ogni nuova funzionalità o correzione crei un branch separato, lavori in isolamento, e quando è pronto lo unisci (merge) a main.
Lavorare con i branch
📘 Creare un branch in Git è istantaneo e gratuito: è solo un puntatore a un commit. Per questo il flusso "un branch per ogni modifica" è lo standard professionale.
Il Merge
Il merge unisce le modifiche di un branch in un altro. Tipicamente: finisci il lavoro sul tuo branch, torni su main e fai il merge del branch.
Unire i branch
I due tipi di merge
Fast-forward: se main non è cambiato nel frattempo, Git sposta semplicemente il puntatore in avanti. Nessun commit extra.
Merge a tre vie: se entrambi i branch hanno nuovi commit, Git crea un merge commit che unisce le due storie.
⚠️ Se entrambi i branch hanno modificato le stesse righe, nasce un conflitto: Git si ferma e ti chiede di decidere. Lo vediamo in dettaglio nella lezione sui conflitti.
Il Workflow Git
Un workflow è la strategia con cui il team organizza branch e rilasci. Conoscere i principali ti aiuta a inserirti in qualsiasi squadra.
Workflow
Come funziona
Ideale per
Feature Branch
Un branch per ogni funzionalità, merge su main via pull request
La maggior parte dei team
GitHub Flow
Feature branch + deploy continuo da main
Web app con rilasci frequenti
Git Flow
Branch strutturati: develop, release, hotfix
Software con versioni pianificate
Trunk-based
Tutti committano su main, branch brevissimi
Team esperti con CI solida
Il ciclo feature-branch completo
Best Practices
Le buone abitudini con Git fanno la differenza tra una storia del progetto leggibile e un caos irrecuperabile.
📝 Commit piccoli e atomici: una modifica logica = un commit
💬 Messaggi chiari: descrivi cosa e perché, non come
🌿 Mai lavorare direttamente su main: sempre un branch
🔄 Pull frequente: integra spesso per evitare conflitti giganti
🧪 Committa solo codice funzionante: chi fa checkout di un tuo commit deve poter compilare
🙈 Mai committare segreti: password, chiavi API e .env restano fuori (usa .gitignore)
📦 Niente file generati: node_modules, build, file binari pesanti non vanno nel repo
🏷️ Tagga le release: ogni versione rilasciata ha il suo tag
⚠️ Un segreto committato resta nella storia anche se lo cancelli nel commit successivo. Se succede: revoca subito la chiave compromessa, poi ripulisci la storia.
Glossario Git
I termini che incontrerai ovunque lavorando con Git e GitHub.
Termine
Significato
Repository
Il progetto con tutta la sua storia
Commit
Una fotografia salvata del progetto
Branch
Linea di sviluppo indipendente
Merge
Unione di due branch
Clone
Copia locale completa di un repo remoto
Fork
Copia di un repo altrui sul tuo account GitHub
Pull Request (PR)
Richiesta di integrare le tue modifiche, con revisione
Remote
Versione del repo su un server (es. origin su GitHub)
HEAD
Puntatore al commit/branch su cui ti trovi
Staging area
Zona di preparazione del prossimo commit
Conflitto
Stesse righe modificate in branch diversi: decide l'umano
Rebase
Rigiocare i commit su una nuova base
Stash
Parcheggio temporaneo di modifiche non committate
Tag
Etichetta permanente su un commit (es. v1.0.0)
Origin
Nome convenzionale del remote principale
Upstream
Il repo originale da cui hai fatto fork
GitHub — Iniziare
GitHub è la piattaforma che ospita oltre 400 milioni di repository ed è il punto d'incontro degli sviluppatori di tutto il mondo. Crea un account gratuito su github.com: ti servirà per il portfolio, per collaborare e per quasi ogni colloquio tecnico.
Creare il primo repository su GitHub
Clicca + in alto a destra → New repository
Scegli un nome (es. mio-progetto)
Decidi se pubblico o privato
Clicca Create repository
Collegare il repo locale a GitHub
📘 Il tuo profilo GitHub è il tuo biglietto da visita da sviluppatore: i recruiter lo guardano prima del CV. Repository curati, README chiari e commit regolari fanno la differenza.
Cos'è SSH
SSH (Secure Shell) è un protocollo per comunicazioni sicure e autenticate. Con GitHub lo usi per autenticarti senza inserire credenziali a ogni push: una coppia di chiavi crittografiche (privata sul tuo PC, pubblica su GitHub) prova la tua identità.
Come funziona
🔑 La chiave privata resta sul tuo computer, non la condividi MAI
🔓 La chiave pubblica la carichi su GitHub
🤝 A ogni connessione, GitHub verifica matematicamente che possiedi la chiave privata corrispondente
Generare una coppia di chiavi SSH
⚠️ Mai condividere, committare o inviare la chiave privata. Se sospetti sia compromessa, eliminala da GitHub e generane una nuova.
Aggiungere la chiave SSH a GitHub
Una volta generata la coppia di chiavi, carichi quella pubblica su GitHub e da quel momento push e pull non chiederanno più credenziali.
Caricare la chiave e testare
💡 In alternativa a SSH puoi usare HTTPS con un Personal Access Token o l'app GitHub CLI (gh auth login): scegli il metodo che preferisci, SSH resta il più comodo a lungo termine.
Impostare il Remote
Un remote è il collegamento a una copia del repository su un server. Il remote principale si chiama per convenzione origin.
Gestire i remote
Modificare il codice su GitHub
GitHub permette di modificare i file direttamente dal browser: comodo per correzioni rapide a README e documentazione, senza passare dal terminale.
Come modificare un file online
Apri il file nel repository su GitHub
Clicca l'icona della matita (Edit this file)
Fai le modifiche nell'editor
In fondo, scrivi un messaggio di commit e clicca Commit changes
💡 Premendo il tasto . (punto) in qualsiasi repository GitHub si apre github.dev: un VS Code completo nel browser, perfetto per modifiche più corpose.
⚠️ Dopo aver modificato online, ricordati di fare git pull nella copia locale: altrimenti al prossimo push avrai un rifiuto perché il remoto è più avanti.
Pull da GitHub
git pull scarica le novità dal remote e le integra nel tuo branch locale. È la combinazione di due operazioni: git fetch (scarica) + git merge (integra).
Scaricare le modifiche
📘 fetch è sempre sicuro: scarica senza modificare nulla. pull modifica i tuoi file. Se vuoi prima ispezionare le novità, usa fetch e guarda le differenze.
Push su GitHub
git push invia i tuoi commit locali al repository remoto, rendendoli visibili a tutti i collaboratori.
Inviare le modifiche
⚠️ git push --force sovrascrive la storia remota e può cancellare il lavoro altrui: non usarlo mai su branch condivisi. Se proprio serve (su un TUO branch), preferisci --force-with-lease che blocca se qualcun altro ha pushato nel frattempo.
Branch su GitHub
GitHub mostra tutti i branch del repository e permette di crearli e gestirli anche dall'interfaccia web.
Dall'interfaccia web
Clicca il menu a tendina dei branch (di solito mostra main)
Digita il nome del nuovo branch
Clicca Create branch: nome from main
Vedere i branch remoti dal terminale
Scaricare un branch da GitHub
Quando un collega (o tu da un altro PC) crea un branch su GitHub, puoi scaricarlo e lavorarci in locale.
Recuperare un branch remoto
Pubblicare un branch su GitHub
Un branch creato in locale non esiste su GitHub finché non lo pubblichi con il push. È il passaggio che precede l'apertura di una pull request.
Pubblicare un branch
GitHub Flow
Il GitHub Flow è il workflow ufficiale proposto da GitHub: semplice, basato su branch e pull request, perfetto per team che rilasciano spesso.
I 6 passi del GitHub Flow
🌿 Crea un branch da main con un nome descrittivo
💻 Fai i commit delle tue modifiche sul branch
📬 Apri una Pull Request per proporre le modifiche
👀 Discussione e review: i colleghi commentano, tu correggi
✅ Merge della PR quando è approvata e i test passano
🧹 Elimina il branch e (se previsto) deploya da main
📘 La regola d'oro del GitHub Flow: main è sempre rilasciabile. Tutto ciò che è su main funziona; tutto ciò che è in sviluppo sta sui branch.
GitHub Pages
GitHub Pages ospita gratuitamente siti statici (HTML, CSS, JS) direttamente da un repository. È il modo più semplice per pubblicare il tuo portfolio o la documentazione di un progetto — questo stesso sito è pubblicato così!
Attivare GitHub Pages
Vai su Settings → Pages nel tuo repository
In Source scegli il branch (di solito main) e la cartella (/ root)
Salva: il sito sarà su https://tuonome.github.io/nome-repo/
Pubblicare un sito in 5 comandi
💡 Per il sito personale principale, chiama il repository tuonome.github.io: sarà raggiungibile direttamente a quell'indirizzo, senza sottocartelle. Puoi anche collegare un dominio personalizzato.
Client grafici per Git
Oltre al terminale, esistono interfacce grafiche che mostrano visivamente branch, diff e storia. Molti professionisti combinano terminale e GUI.
Client
Caratteristiche
GitHub Desktop
Gratuito, semplicissimo, perfetto per iniziare
VS Code (integrato)
Source control già incluso nell'editor + estensione GitLens
GitKraken
Grafo bellissimo, gratuito per repo pubblici
Sourcetree
Gratuito, completo, di Atlassian
Fork
Veloce ed elegante (Mac/Windows)
📘 Consiglio didattico: impara prima i comandi dal terminale per capire cosa succede davvero, poi usa pure la GUI per la comodità quotidiana. Nei colloqui si chiedono i comandi, non i click.
Il Fork
Il fork è una copia di un repository altrui sul tuo account GitHub. È il meccanismo con cui si contribuisce ai progetti open-source: non potendo scrivere direttamente sul repo originale, lavori sulla tua copia e poi proponi le modifiche.
Come fare un fork
Apri il repository che ti interessa su GitHub
Clicca il pulsante Fork in alto a destra
GitHub crea tuonome/nome-progetto: una copia completa di cui sei proprietario
Tenere il fork aggiornato
💡 Su GitHub puoi sincronizzare il fork anche con un click: il pulsante Sync fork nella pagina del tuo repository.
Clonare da GitHub
git clone scarica una copia completa di un repository remoto: tutti i file, tutta la storia, tutti i branch. È il primo comando che esegui quando inizi a lavorare su un progetto esistente.
Clonare un repository
📘 Differenza tra clone e fork: il clone è la copia locale sul tuo PC; il fork è una copia sul tuo account GitHub. Per contribuire a un progetto altrui: prima fork (su GitHub), poi clone (del fork, in locale).
Inviare una Pull Request
La Pull Request (PR) è il cuore della collaborazione su GitHub: proponi le tue modifiche, gli altri le rivedono, ne discutete e — quando tutto è a posto — vengono integrate. È anche il principale strumento di code review nei team.
Il flusso completo di una PR open-source
Scrivere una buona PR
📋 Titolo chiaro e descrizione di cosa cambia e perché
🤏 Piccola e focalizzata: una PR enorme non viene letta volentieri
🧪 Test inclusi se il progetto li ha
📖 Leggi CONTRIBUTING.md: molti progetti hanno regole precise
Git Revert
git revert annulla un commit creando un nuovo commit che ne inverte le modifiche. La storia resta intatta: è il metodo sicuro per annullare, l'unico consigliato sui branch condivisi.
Annullare in sicurezza
📘 Revert vs Reset: revert aggiunge un commit di annullamento (storia preservata, sicuro ovunque); reset cancella commit dalla storia (solo per lavoro locale non ancora pushato).
Git Reset
git reset sposta il branch indietro a un commit precedente, eliminando dalla storia i commit successivi. Potente ma pericoloso: usalo solo su commit non ancora pushati.
I tre tipi di reset
⚠️ --hard elimina le modifiche non committate senza possibilità di recupero. E mai fare reset di commit già pushati su un branch condiviso: usa revert.
Git Amend
git commit --amendsostituisce l'ultimo commit: per correggere il messaggio o aggiungere file dimenticati senza creare un commit "fix" separato.
Correggere l'ultimo commit
⚠️ Amend riscrive il commit (nuovo hash). Se l'avevi già pushato, il push successivo verrà rifiutato: serve --force-with-lease, da usare solo su branch tuoi.
Git Rebase
git rebase "rigioca" i commit del tuo branch sopra un'altra base, tipicamente l'ultima versione di main. Il risultato è una storia lineare e pulita, senza merge commit.
Rebase del branch su main
📘 Merge o rebase? Merge preserva la storia reale (più sicuro), rebase la rende lineare (più leggibile). Regola d'oro: mai rebase di commit già pushati e condivisi con altri.
Git Reflog
Il reflog è il diario segreto di Git: registra ogni spostamento di HEAD (commit, reset, rebase, switch...) degli ultimi 90 giorni. È la tua rete di salvataggio quando pensi di aver perso qualcosa.
Consultare il reflog
💡 Memorizza questo: finché un commit è stato fatto, quasi nulla è davvero perso in Git. Il reflog tiene traccia di tutto per settimane.
Recuperare lavoro perso
Le situazioni di "ho perso tutto!" più comuni e come uscirne. Quasi sempre la soluzione passa dal reflog.
Scenari di recupero
⚠️ L'unica cosa che Git NON può recuperare: modifiche mai aggiunte con git add. Morale: committa spesso, anche commit provvisori — potrai sempre sistemarli con rebase interattivo.
Il file .gitignore
Il file .gitignore elenca file e cartelle che Git deve ignorare: dipendenze, build, file temporanei, segreti. Si mette nella radice del repository e si committa come un file normale.
Un .gitignore tipico
💡 Su gitignore.io generi il .gitignore perfetto per il tuo linguaggio/framework. GitHub li propone anche alla creazione del repo.
⚠️ .gitignore non ha effetto sui file già tracciati. Per smettere di tracciarne uno: git rm --cached file.txt, poi aggiungilo al .gitignore e committa.
Il file .gitattributes
Il file .gitattributes definisce come Git tratta specifici file: fine riga, file binari, diff personalizzati, regole LFS. Risolve i classici problemi di collaborazione tra Windows e Linux/Mac.
Un .gitattributes tipico
📘 Il problema più comune che risolve: Windows usa CRLF come fine riga, Linux/Mac usano LF. Senza .gitattributes, i diff si riempiono di false modifiche su ogni riga.
Git Large File Storage (LFS)
Git è ottimizzato per il testo, non per file grandi: video, PSD, dataset e binari gonfiano il repository per sempre (ogni versione resta nella storia). Git LFS risolve: nel repo va solo un puntatore, il file vero sta su un server dedicato.
Usare Git LFS
⚠️ GitHub blocca i file oltre i 100 MB e avvisa già a 50 MB. Se devi versionare file grandi, configura LFS prima di committarli: rimuoverli dalla storia a posteriori è laborioso.
Firmare commit e tag
La firma crittografica dei commit prova che sei davvero tu l'autore: chiunque può impostare nome ed email altrui nella config, ma non può falsificare la tua firma. Su GitHub i commit firmati mostrano il badge Verified.
Firmare con GPG o SSH
📘 Molte aziende e progetti open-source richiedono commit firmati sui branch protetti. Configurarlo una volta ti mette a posto per sempre.
Cherry-pick e Patch
git cherry-pick copia un singolo commit da un branch a un altro: utile per portare una correzione su più versioni. Le patch esportano commit come file, condivisibili anche senza un server comune.
Cherry-pick e patch
Risolvere i conflitti di merge
Un conflitto nasce quando due branch modificano le stesse righe dello stesso file: Git non può decidere da solo e ti chiede di scegliere. Niente panico: è normale e si risolve in pochi passaggi.
Anatomia e risoluzione di un conflitto
💡 VS Code mostra i conflitti con pulsanti cliccabili: Accept Current / Accept Incoming / Accept Both. Per ridurre i conflitti: pull frequenti, branch brevi, e coordinarsi su chi tocca quali file.
Git e CI/CD
La CI/CD collega Git all'automazione: a ogni push o pull request, una pipeline esegue automaticamente test, lint e deploy. Su GitHub si usa GitHub Actions, configurato con file YAML nel repository.
Una GitHub Action di base
Cosa puoi automatizzare
🧪 Test automatici su ogni PR (blocco del merge se falliscono)
📦 Build e pubblicazione di pacchetti e release
🚀 Deploy automatico su push a main
🔍 Analisi di sicurezza e qualità del codice
📘 Con i branch protetti (Settings → Branches) puoi imporre che nessuno possa mergiare su main senza review approvata e test verdi.
Git Hooks
Gli hook sono script che Git esegue automaticamente in momenti precisi: prima di un commit, prima di un push, dopo un merge. Servono a imporre controlli di qualità in locale.
Un hook pre-commit
📘 Gli hook in .git/hooks sono locali e non si committano. Per condividerli con il team si usano strumenti come husky (JavaScript) o pre-commit (Python).
Git Submodules
I submodule includono un repository dentro un altro: utile quando un progetto dipende da una libreria che versioni separatamente. Il repo padre registra solo il commit esatto del submodule.
Gestire i submodule
⚠️ I submodule sono potenti ma scomodi (doppi commit, dimenticanze di update). Per dipendenze normali preferisci un package manager (npm, pip...); usa i submodule solo quando serve davvero il sorgente versionato insieme.
Remote avanzati
Tecniche avanzate per lavorare con più remote e scenari complessi: più server, mirror, push selettivi.
Scenari multi-remote
Praticare Git online
Ogni esempio del corso ha il pulsante ▶ Provalo tu: apre un editor dove puoi leggere e modificare i comandi con la sintassi colorata. Per eseguirli davvero, usa il terminale del tuo computer o uno di questi ambienti.
Dove esercitarti
🎮 Learn Git Branching — simulatore visuale di branch, merge e rebase, in italiano: il miglior modo di capire i branch
💻 Il tuo terminale — installa Git da git-scm.com: niente batte la pratica reale
🐙 GitHub — account gratuito per repository, PR e Pages
📚 Oh My Git! — un videogioco open-source per imparare Git
La sessione di pratica perfetta
Esercizi Git
Esercizi pratici progressivi: fai ognuno nel tuo terminale, in un repository di prova.
Livello base
Crea un repository, aggiungi un file README.md e fai il primo commit
Modifica il file, controlla le differenze con git diff, poi committa
Crea 3 commit e visualizza la storia con git log --oneline
Metti in staging solo uno di due file modificati e committa
Livello intermedio
Crea un branch, fai due commit, torna su main e fai il merge
Provoca volontariamente un conflitto (modifica la stessa riga su due branch) e risolvilo
Usa git stash per cambiare branch con lavoro in sospeso
Pubblica un repository su GitHub e attiva GitHub Pages
Livello avanzato
Annulla un commit con revert e uno con reset, osservando la differenza in git log
Fai un rebase interattivo per unire (squash) 3 commit in uno
Recupera un commit "perso" dopo un reset --hard usando il reflog
Fai fork di un progetto open-source, correggi un refuso e apri la tua prima pull request
🎯 Sfida
Simula un team con te stesso: due cloni dello stesso repository in cartelle diverse ("collega A" e "collega B"). Fai modifiche incrociate, push e pull da entrambi, e gestisci i conflitti che nascono. È l'esperienza più vicina al lavoro reale.
Quiz Git
Verifica le tue conoscenze. Risposte in fondo.
Qual è la differenza tra Git e GitHub?
Cosa fa git add?
Quali sono le tre aree di Git?
Differenza tra git fetch e git pull?
Quando usare revert invece di reset?
Cosa fa git clone?
Cos'è una pull request?
Come si chiamano i marcatori che Git inserisce nei file in conflitto?
Cosa elenca il file .gitignore?
Quale comando mostra ogni spostamento di HEAD, anche dopo un reset?
📘 Risposte: 1) Git è il software di versionamento locale, GitHub la piattaforma online che ospita i repository. 2) Mette le modifiche nella staging area. 3) Working directory, staging area, repository. 4) fetch scarica senza integrare, pull scarica e integra (fetch+merge). 5) Su commit già pushati/condivisi: revert preserva la storia. 6) Scarica una copia completa di un repo remoto. 7) Una proposta di integrazione delle proprie modifiche, con revisione. 8) <<<<<<<, =======, >>>>>>>. 9) File e cartelle che Git deve ignorare. 10) git reflog.
Programma del corso
La mappa completa di tutto ciò che copre questo corso, dal primo commit alle tecniche avanzate.
Fondamenti: cos'è il versionamento, installazione, configurazione, primo repository
Il ciclo quotidiano: staging, commit, storia, tag, stash
Branch e merge: sviluppo parallelo, unione, workflow professionali
Git si impara facendo: il piano alterna teoria e pratica quotidiana. Bastano 2-3 settimane per diventare autonomi.
Periodo
Obiettivo
Giorni 1-3
Installazione, config, init, add, commit, log: il ciclo base
Giorni 4-6
Branch, switch, merge + esercizi su Learn Git Branching
Giorni 7-9
GitHub: account, SSH, push, pull, clone, primo repo pubblicato
Giorni 10-12
Pull request, fork, conflitti di merge (provocali apposta!)
Giorni 13-15
Annullare: revert, reset, amend, stash, reflog
Settimana 3
GitHub Pages, .gitignore, rebase, CI/CD di base + usa Git in OGNI tuo progetto
💡 Il vero segreto: da oggi, ogni tuo progetto (anche gli esercizi degli altri corsi) vive in un repository Git. In un mese i comandi saranno automatici come salvare un file.
Domande da colloquio
Git compare in quasi tutti i colloqui tecnici. Queste sono le domande più frequenti.
🔹 Spiega la differenza tra merge e rebase: quando usi l'uno o l'altro?
🔹 Differenza tra git reset --soft, --mixed e --hard
🔹 Come annulli un commit già pushato su un branch condiviso?
🔹 Come risolvi un conflitto di merge? Descrivi i passaggi
🔹 Cosa fa git cherry-pick e quando lo useresti?
🔹 Cos'è il reflog e come recupereresti un commit perso?
🔹 Descrivi il workflow Git del tuo ultimo team (o il GitHub Flow)
🔹 Perché push --force è pericoloso? Cosa usare al suo posto?
🔹 Hai mai committato un segreto per errore? Cosa faresti?
🔹 Differenza tra fork e clone, e tra fetch e pull
💡 Le domande Git nei colloqui puntano a capire se hai lavorato davvero in team: rispondi con episodi concreti ("una volta ho dovuto recuperare un branch eliminato...") e farai un'ottima impressione.
Bootcamp Git & GitHub
Un percorso intensivo per padroneggiare Git e GitHub in una settimana, con esercitazioni guidate e simulazioni di lavoro in team.
Cosa imparerai
✅ Il ciclo completo: commit, branch, merge senza paura
✅ Risolvere conflitti e recuperare da qualsiasi errore
✅ Pubblicare il tuo portfolio con GitHub Pages
✅ Automazione con GitHub Actions
✅ Simulazione di collaborazione in team su un progetto reale
📘 Vuoi un percorso guidato con un docente? Prenota una lezione o scrivi dal modulo contatti: prepariamo un piano su misura, anche per gruppi e classi.
Certificazione Git
Le certificazioni Git attestano le tue competenze di versionamento e collaborazione: un plus concreto sul CV, anche se il portfolio GitHub resta la prova più convincente.
Certificazione
Ente
Note
GitHub Foundations
GitHub
Ufficiale, ideale per iniziare
GitHub Actions / Advanced Security
GitHub
Specializzazioni ufficiali successive
Git Certificate
W3Schools
Base, buono per il CV
GitLab Certified Associate
GitLab
Se il team usa GitLab
Il tuo profilo GitHub
—
Contributi regolari valgono più di ogni badge
Come prepararsi
📚 Padroneggia branch, merge, rebase e la risoluzione dei conflitti
🐙 Conosci il flusso PR completo: fork, branch, review, merge
🛠️ Sai annullare qualsiasi errore (revert, reset, reflog)
🟩 Mantieni il profilo GitHub attivo: contribuzioni costanti, README curati
Conclusione — E ora?
Hai completato il corso Git e GitHub! Ora sai versionare il codice, lavorare con branch e merge, collaborare con pull request, pubblicare siti con GitHub Pages, annullare qualsiasi errore e automatizzare i controlli con la CI/CD.
I tuoi prossimi passi
🐙 Metti tutti i tuoi progetti su GitHub: da oggi ogni esercizio dei corsi vive in un repository
🌍 Contribuisci all'open-source: cerca issue etichettate good first issue e apri la tua prima PR vera
📄 Pubblica il tuo portfolio con GitHub Pages usando HTML e CSS
⚙️ Approfondisci GitHub Actions per testare e deployare in automatico i progetti Node.js
👥 Lavora in team: proponi a un amico un progetto a quattro mani con PR e review reciproche
🎯 La tua sfida finale
Crea il tuo repository-portfolio: un sito pubblicato su GitHub Pages che presenta i tuoi progetti, sviluppato interamente con il flusso professionale — un branch per ogni sezione, pull request verso main, commit firmati e una GitHub Action che valida l'HTML a ogni push. Sarà contemporaneamente il tuo biglietto da visita e la prova delle tue competenze Git.
