Git 21
🔀 Git & GitHub · Modulo 4 · Lezione 21
GitHub Projects e Kanban 📋
Board Kanban · Colonne e automazioni · Collegare issue e PR · Gestione visuale del progetto
📋 Le issue sono la lista delle cose da fare. I Projects sono la mappa che mostra dove sta ogni cosa. Con GitHub Projects crei una board visuale — un tabellone con colonne come “Da fare”, “In corso” e “Fatto” — dove ogni issue e ogni PR è una scheda che si sposta da una colonna all’altra. A colpo d’occhio vedi chi sta lavorando su cosa, cosa è bloccato e cosa manca per la consegna.
🎯 Obiettivi della lezione
- Capire cos’è una Kanban board e perché è utile per gestire un progetto
- Creare un GitHub Project con la vista Board
- Configurare le colonne (To Do, In Progress, Done)
- Aggiungere issue e PR al progetto
- Configurare le automazioni per spostare le schede automaticamente
- Usare le viste Table e Roadmap per prospettive diverse
📖 1. Teoria
1.1 — Cos’è il metodo Kanban
Kanban è un metodo di gestione del lavoro nato in Toyota negli anni ’50 e adottato massicciamente nello sviluppo software. L’idea è semplice: visualizza il lavoro come schede su un tabellone, organizzate in colonne che rappresentano le fasi del processo. Ogni scheda si sposta da sinistra a destra man mano che il lavoro avanza.
1.2 — GitHub Projects: la Kanban board integrata
GitHub Projects (la versione attuale, chiamata “Projects V2”) è un sistema di gestione progetti integrato direttamente in GitHub. Le schede del progetto possono essere issue, pull request o note libere — tutto collegato al codice.
| Tipo di elemento | Cos’è | Collegamento al codice |
|---|---|---|
| Issue | Un task, bug o feature dal tuo repository | Collegata a commit e PR con #N e closes #N |
| Pull Request | Una PR aperta nel tuo repository | Collegata direttamente al codice e alle review |
| Draft issue | Un’idea o nota rapida (non ancora un’issue vera) | Nessun collegamento — può essere convertita in issue |
1.3 — Creare un GitHub Project
📌 Dove vivono i Projects? I Projects V2 sono legati al tuo account o alla tua organizzazione, non al singolo repository. Questo significa che un Project può contenere issue e PR da più repository — utile se il tuo progetto scolastico è diviso in repo separati (frontend, backend, documentazione). Il link tra Project e repository si crea dalla tab “Projects” del repo.
1.4 — Aggiungere elementi al progetto
Ci sono diversi modi per popolare la board con le tue issue e PR:
| Metodo | Come | Quando usarlo |
|---|---|---|
| Dal Project: + Add item | Clicca “+ Add item” in fondo a una colonna → cerca l’issue per numero o titolo → selezionala | Per aggiungere issue esistenti al progetto |
| Dall’issue: sidebar “Projects” | Apri l’issue → nella sidebar destra → “Projects” → seleziona il progetto | Quando crei una nuova issue e vuoi aggiungerla subito |
| Draft: nota rapida | Nella board, clicca “+ Add item” → scrivi direttamente il testo → premi Invio | Per idee veloci che convertirai in issue dopo |
| Bulk: aggiungi tutto | Clicca “+ Add item” → “+ Add item from repository” → seleziona tutto → Add | Per popolare il progetto con tutte le issue esistenti |
1.5 — Personalizzare le colonne
Le 3 colonne predefinite (Todo, In Progress, Done) sono un buon punto di partenza. Ma puoi personalizzarle per il tuo workflow. Le colonne corrispondono ai valori di un campo personalizzato chiamato “Status”.
1.6 — Automazioni: spostare le schede automaticamente
La parte migliore: puoi configurare il progetto per spostare le schede automaticamente quando succedono certe cose nel repository. Ad esempio, quando una issue viene chiusa, la sua scheda si sposta in “Done”.
| Evento | Automazione | Come attivare |
|---|---|---|
| Issue/PR aggiunta al progetto | Imposta automaticamente lo Status a Todo | Workflow “Item added to project” |
| Issue chiusa | Sposta automaticamente in Done | Workflow “Item closed” |
| PR merged | Sposta automaticamente in Done | Workflow “Pull request merged” |
| Issue riaperta | Sposta automaticamente in Todo | Workflow “Item reopened” |
📌 Lo spostamento in “In Progress” resta manuale. Le automazioni coprono l’inizio (aggiunta → Todo) e la fine (chiusura → Done), ma lo spostamento in “In Progress” lo fai tu trascinando la scheda quando inizi a lavorare. Questo è intenzionale: GitHub non può sapere quando inizi a lavorare — solo tu lo sai.
1.7 — Le 3 viste del progetto
GitHub Projects offre 3 viste diverse sugli stessi dati. Puoi passare da una all’altra in qualsiasi momento:
1.8 — Campi personalizzati
Oltre allo Status, puoi aggiungere campi personalizzati alle schede per tracciare informazioni extra. Ecco i più utili per un progetto scolastico:
| Campo | Tipo | Esempio di valori | A cosa serve |
|---|---|---|---|
| Priorità | Single select | 🔴 Alta, 🟡 Media, 🟢 Bassa | Decidere cosa fare prima |
| Dimensione | Single select | 🐛 Piccola, 🐕 Media, 🐘 Grande | Stimare l’impegno |
| Sprint / Settimana | Iteration | Settimana 1, Settimana 2… | Pianificare il lavoro per periodi |
| Scadenza | Date | 2026-04-15 | Tracciare le scadenze (utile nella vista Roadmap) |
💻 2. Esempi guidati
Esempio A — Creare il Project Board per un progetto di gruppo
Esempio B — Il workflow quotidiano con la board
closes #5 → Giulia revisiona e approva → merge. Automaticamente, la scheda #5 si sposta in Done. Marco prende la prossima issue dalla colonna Todo.🏋️ 3. Esercizi
🟢 Esercizio 1 — Crea il tuo primo Project (Facile)
b) Dai un nome al progetto.
c) Aggiungi almeno 3 issue esistenti (o crea 3 issue nuove e aggiungile).
d) Trascina una issue in “In Progress” e una in “Done”.
e) Guarda la board: il flusso visuale ha senso?
🔵 Esercizio 2 — Automazioni in azione (Medio)
b) Crea una nuova issue nel repository e aggiungila al progetto. Appare in “Todo”?
c) Chiudi l’issue su GitHub (con un commento “completata”). La scheda si sposta in “Done”?
d) Riapri l’issue. Cosa succede nella board? (Se hai attivato “Item reopened” → Todo, torna lì.)
e) Ora prova: crea un branch, fai un commit con
closes #N, pusha, apri una PR, fai merge. La scheda si sposta in Done automaticamente?
🟠 Esercizio 3 — Campi personalizzati e vista Table (Medio)
b) Assegna una priorità a ciascuna issue.
c) Passa alla vista Table (clicca il tab in alto). Vedi la colonna Priorità?
d) Ordina per priorità: cliccando sull’intestazione della colonna.
e) Filtra: mostra solo le issue con priorità “Alta”.
f) Crea una seconda vista Board chiamata “Per priorità” raggruppata per il campo Priorità invece che per Status.
🟣 Esercizio 4 — Project completo per un progetto di gruppo (Difficile)
a) Crea un Project con vista Board e 4 colonne: Backlog, Todo, In Progress, Done.
b) Attiva tutte le automazioni disponibili.
c) Aggiungi i campi: Priorità (Alta/Media/Bassa) e Dimensione (Piccola/Media/Grande).
d) Crea almeno 8 issue che coprano tutto il progetto (homepage, about, contatti, stili, README, ecc.).
e) Aggiungi tutte le issue al progetto. Assegna priorità e dimensione a ciascuna.
f) Assegna le issue ai membri del team. Ogni persona ha 2 issue.
g) Sposta 2 issue in “In Progress” (quelle su cui iniziate a lavorare).
h) Crea una vista Table con filtro “Assignee = me” per vedere solo le tue issue.
i) Fai uno screenshot della board — è il “piano di progetto” del tuo team.
❓ 4. Quiz di verifica
1. Cos’è una Kanban board e perché è utile nella gestione di un progetto?
Mostra risposta
Una Kanban board è un tabellone visuale con colonne che rappresentano le fasi del lavoro (tipicamente: Da fare, In corso, Fatto). Ogni attività è una scheda che si sposta da sinistra a destra man mano che avanza. È utile perché dà visibilità immediata sullo stato di tutto il progetto: a colpo d’occhio vedi cosa è stato fatto, cosa è in corso, cosa è bloccato e cosa resta da fare. Facilita la coordinazione del team: ognuno vede chi sta lavorando su cosa, senza doverlo chiedere. È un metodo nato in Toyota e adottato da quasi tutto lo sviluppo software moderno.
2. Qual è la differenza tra un’issue e un draft issue in un GitHub Project?
Mostra risposta
Un’issue è un elemento reale del repository: ha un numero (#N), appare nella tab Issues, può essere collegata a commit e PR, ha label e assignee. Un draft issue è una nota rapida che esiste solo nel progetto: non ha un numero, non appare nel repository, non può essere referenziata nei commit. È utile per annotare idee veloci che non sono ancora abbastanza definite per diventare issue vere. Puoi convertire un draft in issue cliccando i tre puntini sulla scheda e selezionando “Convert to issue”.
3. Come funziona l’automazione “Item closed” → Done?
Mostra risposta
Quando un’issue o una PR che è nel progetto viene chiusa (manualmente, o automaticamente tramite closes #N in un merge), il workflow sposta la sua scheda nella colonna Done automaticamente. Non devi andare sulla board e trascinarla tu. Si attiva nei workflow del progetto: menu ⋯ → Workflows → “Item closed” → imposta Status = Done → toggle On. È l’automazione più utile perché elimina il lavoro manuale di aggiornamento della board dopo ogni merge.
4. Perché lo spostamento in “In Progress” non è automatizzabile?
Mostra risposta
Perché GitHub non può sapere quando inizi a lavorare su un’issue. L’inizio di un’attività è una decisione umana che non corrisponde a un evento tecnico preciso. Potresti creare un branch senza iniziare subito a lavorarci, o potresti lavorare localmente senza pushare per ore. L’aggiunta al progetto e la chiusura sono eventi chiari (GitHub li vede), ma l’inizio del lavoro è ambiguo. Per questo lo spostamento in “In Progress” resta manuale: trascini la scheda quando decidi di iniziare.
5. Quali sono le 3 viste disponibili in un GitHub Project?
Mostra risposta
Board (Kanban con colonne per trascinare le schede — la vista principale per il lavoro quotidiano), Table (tabella simile a un foglio di calcolo, con ordinamento e filtri — utile per analizzare i dati), e Roadmap (timeline temporale con date di inizio e fine — utile per pianificare le scadenze). Puoi avere più viste dello stesso progetto e passare da una all’altra. Ogni vista può avere filtri e raggruppamenti diversi: ad esempio, una vista Board per status e una vista Board per priorità sugli stessi dati.
6. Un GitHub Project può contenere issue da più repository?
Mostra risposta
Sì. A differenza delle vecchie “project boards” legate al singolo repository, i GitHub Projects V2 sono legati all’account o all’organizzazione, non al repository. Puoi aggiungere issue e PR da qualsiasi repository a cui hai accesso. Questo è utile per progetti complessi divisi in più repository (es. frontend e backend separati, o documentazione in un repo a parte). Tutte le issue appaiono sulla stessa board, indipendentemente dal repository di provenienza.
📚 Riepilogo della lezione
- Kanban = tabellone visuale con colonne (To Do → In Progress → Done)
- GitHub Projects: board integrata con issue e PR del repository
- Creare: Repository → Projects → New project → Board
- Colonne personalizzabili tramite il campo Status
- Aggiungere elementi: “+ Add item” nella board, oppure dalla sidebar dell’issue
- Automazioni: item aggiunto → Todo · item chiuso → Done · PR merged → Done
- In Progress resta manuale — trascini quando inizi a lavorare
- 3 viste: Board (kanban) · Table (tabella) · Roadmap (timeline)
- Campi personalizzati: Priorità, Dimensione, Sprint, Scadenza
- I Projects V2 possono contenere issue da più repository
Prossima lezione →
Lezione 22 — Milestone e release
Raggruppare le issue in obiettivi. Creare release con tag.
Semantic versioning. Distribuire il progetto.
Corso Git & GitHub · Per studenti e insegnanti · Lezione 21 di 45