Git 32
🔀 Git & GitHub · Modulo 6 · Lezione 32
Consegnare compiti via repository 📝
Il workflow per le consegne · Commit puliti · Scadenze · Convenzioni · Errori da evitare
📝 Addio file ZIP via email. Addio chiavette USB. Consegnare un compito con Git e GitHub significa: il prof vede esattamente quando hai lavorato, come hai progredito, ogni modifica che hai fatto. Non c’è bisogno di scrivere “Versione finale DEFINITIVA (2).zip” — la storia dei commit racconta tutto. In questa lezione impari il workflow per consegnare compiti in modo professionale.
🎯 Obiettivi della lezione
- Capire i vantaggi della consegna via repository rispetto ai metodi tradizionali
- Seguire il workflow corretto per consegnare un compito
- Scrivere commit puliti e significativi
- Rispettare le scadenze con i commit timestampati
- Evitare gli errori più comuni nella consegna
- Conoscere i due modelli: repository personale vs fork del template
📖 1. Teoria
1.1 — Perché consegnare via repository
Il prof riceve 25 ZIP da rinominare e aprire
Nessuna traccia di quando hai lavorato
“L’ho mandato! Controlla lo spam…”
Versioni diverse su chiavette diverse
Niente feedback strutturato
Ogni commit ha data e ora — la timeline del lavoro
Il prof vede come hai progredito, non solo il risultato
Nessun file perso — tutto è su GitHub
Feedback diretto nelle PR o nelle issue
Impari un workflow professionale reale
1.2 — I due modelli di consegna
Contro: il prof deve raccogliere i link uno per uno.
Contro: richiede che gli studenti sappiano fare fork (Lez. 19).
📌 Se il prof usa GitHub Classroom (Modulo 7), il processo è ancora più automatizzato: lo studente clicca un link, il repository viene creato automaticamente, e il prof vede tutti i lavori in una dashboard. Ma anche senza Classroom, i modelli A e B funzionano benissimo.
1.3 — Il workflow della consegna (Modello A)
con README
con messaggi chiari
non solo alla fine
Tag versione finale
prima della scadenza
# Su GitHub: New repository → nome: “compito-html-rossi-mario”
# ☑ Add a README file → Create repository
$ git clone git@github.com:mario-rossi/compito-html-rossi-mario.git
$ cd compito-html-rossi-mario
# === PASSO 2: Lavora con commit frequenti ===
$ git ac “Aggiunta struttura HTML base”
# …lavora…
$ git ac “Aggiunto CSS per header e footer”
# …lavora…
$ git ac “Implementato form contatti con validazione”
# === PASSO 3: Pusha regolarmente ===
$ git push ← ogni sessione di lavoro, non solo alla fine
# === PASSO 4: Completa con README e tag ===
# Compila il README con: descrizione, come avviare, cosa hai fatto
$ git ac “Compilato README con istruzioni”
$ git tag -a v1.0 -m “Consegna finale”
$ git push && git push origin v1.0
# === PASSO 5: Consegna ===
# Invia al prof il link: https://github.com/mario-rossi/compito-html-rossi-mario
1.4 — Commit puliti: la regola d’oro
Il prof vede i tuoi commit. Sono il “diario di bordo” del tuo lavoro. Commit buoni dimostrano che hai lavorato con metodo; commit cattivi danno l’impressione opposta.
| ❌ Commit cattivi | ✅ Commit buoni |
|---|---|
| “fix” | “Corretto errore validazione email nel form contatti” |
| “aggiornamento” | “Aggiunto stile responsive per la sezione hero” |
| “asdkjasd” | “Creata struttura HTML della pagina about” |
| “tutto fatto” | “Completata gallery con lightbox JavaScript” |
| 1 commit con tutto il compito | 10-15 commit che raccontano il progresso |
1.5 — Il README del compito
Il README è la prima cosa che il prof legge. Per un compito scolastico, deve contenere almeno queste sezioni:
## Autore
– **Nome:** Mario Rossi
– **Classe:** 4A Informatica
– **Data consegna:** 15 aprile 2026
## Descrizione
Sito personale con 3 pagine: homepage, about e contatti.
Include form di contatto con validazione JavaScript.
## Come visualizzare
1. Clona il repository
2. Apri `index.html` nel browser
3. Oppure visita: https://mario-rossi.github.io/compito-html/
## Struttura
“`
├── index.html # Homepage
├── about.html # Pagina about
├── contatti.html # Form contatti
├── style.css # Stili
├── script.js # Validazione form
└── img/ # Immagini
“`
## Cosa ho imparato
– Flexbox e Grid per il layout responsive
– Validazione form con JavaScript vanilla
– Accessibilità: alt nelle immagini, label nei form
1.6 — Scadenze: i commit hanno data e ora
Ogni commit ha un timestamp preciso. Il prof può verificare quando hai lavorato. Questo è sia un vantaggio (dimostra il tuo impegno nel tempo) che un vincolo (non puoi barare sulla data).
$ git log –format=”%h %ai %s” –reverse
a1b2c3d 2026-04-01 14:30:00 Struttura HTML iniziale
d4e5f6g 2026-04-03 16:45:00 Aggiunto CSS header e footer
h7i8j9k 2026-04-08 10:20:00 Implementato form contatti
l0m1n2o 2026-04-12 20:15:00 Aggiunta validazione JS
p3q4r5s 2026-04-14 18:00:00 README e pulizia finale
← 5 sessioni di lavoro distribuite su 2 settimane ✅
# Questo invece è sospetto:
x1y2z3a 2026-04-14 23:55:00 Tutto fatto
← 1 commit 5 minuti prima della scadenza ❌
1.7 — Errori comuni da evitare
| Errore | Problema | Soluzione |
|---|---|---|
| Un solo commit gigante | Il prof non vede il progresso. Sembra fatto all’ultimo minuto. | Committa dopo ogni parte completata. |
| Committare node_modules o file generati | Il repository diventa enorme. GitHub rallenta. | Aggiungi .gitignore PRIMA del primo commit. |
| Repository privato senza aggiungere il prof | Il prof non può accedere al tuo lavoro. | Rendilo pubblico o aggiungi il prof come collaboratore. |
| README vuoto | Il prof non sa cosa hai fatto o come avviare il progetto. | Compila il README con le sezioni della 1.5. |
| Push solo il giorno della consegna | Se qualcosa va storto (conflitti, errori push), non hai tempo per risolvere. | Push ogni volta che lavori. Consegna il giorno prima della scadenza. |
| Copiare il compito di un compagno | I timestamp dei commit lo rivelano. Il prof può confrontare le storie. | Lavora in modo autonomo. Chiedi aiuto al prof o ai compagni, non il codice. |
💻 2. Esempi guidati
Esempio A — Consegna con repository personale (Modello A)
git ac "Struttura HTML con 3 pagine" → git push.git tag -a v1.0 -m "Consegna". Push con tag. Aggiungi il prof come collaboratore.Esempio B — Consegna con fork del template (Modello B)
# 1. Fork
# Su GitHub: vai al repo del prof → Fork → Create fork
# 2. Clone del tuo fork
$ git clone git@github.com:mario-rossi/compito-sito-personale.git
$ cd compito-sito-personale
# 3. Lavora (commit frequenti, push regolari)
$ git ac “Aggiunta homepage con header responsive”
$ git push
# …continua a lavorare…
# 4. Quando hai finito: tag di consegna
$ git tag -a v1.0 -m “Consegna finale”
$ git push && git push origin v1.0
# 5. Il prof vede il tuo fork dalla pagina “Forks” del template
# oppure puoi aprire una PR dal tuo fork al repo del prof
🏋️ 3. Esercizi
🟢 Esercizio 1 — Simula una consegna (Facile)
b) Clona, crea un file
index.html con “Ciao mondo”. Committa: “Struttura HTML iniziale”.c) Aggiungi un
style.css. Committa: “Aggiunto stile base”.d) Modifica il README con le sezioni della 1.5 (Autore, Descrizione, Come visualizzare).
e) Crea il tag
v1.0. Pusha tutto (incluso il tag).f) Verifica su GitHub: quanti commit? Il tag è visibile? Il README è completo?
🔵 Esercizio 2 — Messaggi di commit migliorati (Medio)
b) Fai almeno 8 commit, ciascuno con un messaggio descrittivo che inizia con un verbo.
c) Nessun messaggio deve essere generico (“fix”, “update”, “cose”).
d) Alla fine, esegui
git log --oneline e leggi la lista: racconta una storia coerente del lavoro?e) Condividi il repository con un compagno: riesce a capire cosa hai fatto solo leggendo i commit?
🟠 Esercizio 3 — Consegna con fork (Medio)
a) Il “prof” crea un repository template con: README (consegna del compito), struttura cartelle, .gitignore.
b) Lo “studente” fa fork, clona, lavora con commit multipli, pusha.
c) Lo “studente” crea il tag v1.0 e apre una PR dal fork al repo del prof.
d) Il “prof” revisiona la PR: i commit sono chiari? Il README è compilato? Mancano file?
e) Scambiate i ruoli e ripetete.
🟣 Esercizio 4 — Consegna professionale completa (Difficile)
a) Crea il repository. Aggiungi
.gitignore, LICENSE (MIT), e README template.b) Lavora per almeno 3 sessioni separate con almeno 4 commit ciascuna (12+ commit totali).
c) Ogni sessione di lavoro termina con un push.
d) A metà lavoro: crea una milestone “Consegna” e 3-4 issue per le parti rimanenti.
e) Completa le issue con commit che le chiudono (
closes #N).f) README completo con tutte le sezioni della 1.5 + sezione “Cosa ho imparato”.
g) Tag
v1.0 con messaggio descrittivo. Crea una Release su GitHub con release notes.h) Se hai il CI configurato: verifica che il workflow è verde al momento della consegna.
i) Se hai Pages configurato: il sito è online e funzionante.
❓ 4. Quiz di verifica
1. Perché consegnare via repository è meglio che inviare un file ZIP?
Mostra risposta
Il repository mostra la storia completa del lavoro: ogni commit ha data, ora e descrizione di cosa è stato fatto. Il prof vede il progresso nel tempo, non solo il risultato finale. Non ci sono file persi, non serve rinominare ZIP, il feedback può avvenire direttamente nelle PR o nelle issue. Inoltre lo studente impara un workflow professionale reale — nelle aziende nessuno invia ZIP, tutti usano Git.
2. Quanti commit dovrebbe avere un compito medio?
Mostra risposta
Circa 10-15 commit per un compito di media complessità. La regola è committare ogni volta che completi una parte funzionante: la struttura HTML, lo stile di una sezione, una feature JavaScript, una correzione. Un solo commit con tutto il compito è un segnale negativo — non mostra il percorso di lavoro. Ma anche 50 micro-commit (“aggiunto spazio”, “tolto spazio”) sono eccessivi. L’obiettivo è che la lista dei commit racconti una storia coerente: “prima ho fatto la struttura, poi lo stile, poi la logica, poi la pulizia”.
3. Perché è importante pushare regolarmente e non solo alla scadenza?
Mostra risposta
Due motivi. Sicurezza: se il computer si rompe, il lavoro è perso se non l’hai pushato. I commit in locale non sono un backup — servono su GitHub. Gestione del rischio: se qualcosa va storto con il push il giorno della scadenza (conflitti, problemi SSH, GitHub down), non hai tempo per risolvere. Pushare dopo ogni sessione di lavoro elimina entrambi i rischi. Inoltre, i push intermedi mostrano al prof che hai lavorato nel tempo — non all’ultimo minuto.
4. Cosa deve contenere il README di un compito?
Mostra risposta
Almeno: Autore (nome, classe, data consegna), Descrizione (cosa fa il progetto), Come visualizzare (istruzioni per far funzionare il progetto — clone + come avviare), Struttura (albero dei file con descrizione), e idealmente Cosa ho imparato (riflessione personale). Il README è la prima cosa che il prof legge — un README vuoto o con solo “compito di informatica” è un’opportunità persa. È anche un esercizio di comunicazione: saper spiegare cosa hai fatto è importante quanto averlo fatto.
5. A cosa serve creare un tag v1.0 al momento della consegna?
Mostra risposta
Il tag segna il punto esatto della consegna nella storia dei commit. Anche se continui a lavorare dopo la scadenza (es. per migliorare il progetto), il tag v1.0 identifica la versione che hai consegnato. Il prof può fare git checkout v1.0 per vedere esattamente lo stato del progetto al momento della consegna. È lo stesso meccanismo usato nell’industria per marcare le release (Lezione 22). Il tag è anche la base per creare una Release su GitHub con le note di consegna.
6. Il prof può scoprire se hai copiato il compito da un compagno?
Mostra risposta
Sì, molto facilmente. Il prof può confrontare le storie dei commit dei due repository: se il codice è identico ma i commit hanno timestamp diversi (o lo stesso timestamp), è evidente. GitHub Classroom ha anche strumenti di rilevamento plagio integrati. Inoltre, un compito copiato ha tipicamente 1-2 commit generici, mentre un lavoro autentico ha una progressione naturale di commit nel tempo. Il consiglio: se sei in difficoltà, chiedi aiuto al prof o ai compagni — chiedere spiegazioni è OK, copiare codice no.
📚 Riepilogo della lezione
- 2 modelli: repository personale (semplice) vs fork del template (strutturato)
- Workflow: crea repo → lavora (commit frequenti) → push regolari → README → tag → consegna
- Commit puliti: 10-15 commit con messaggi descrittivi che iniziano con un verbo
- I commit hanno data e ora — il prof vede quando hai lavorato
- README del compito: autore, descrizione, come avviare, struttura, cosa ho imparato
- Tag v1.0 = punto esatto della consegna nella storia dei commit
- Push ogni sessione = backup + dimostrazione di lavoro continuo
- Errori: no commit unico gigante, no node_modules, no README vuoto, no push solo alla scadenza
Prossima lezione →
Lezione 33 — Lavorare in gruppo
Organizzare un progetto di team con Git. Dividersi il lavoro.
Gestire conflitti, PR incrociate e code review tra compagni.
Corso Git & GitHub · Per studenti e insegnanti · Lezione 32 di 45