Git 33
🔀 Git & GitHub · Modulo 6 · Lezione 33
Lavorare in gruppo 👥
Organizzare il team · Dividersi il lavoro · PR incrociate · Gestire conflitti · Code review tra pari
👥 Lavorare da soli con Git è semplice. Lavorare in team è dove le cose diventano interessanti. Chi fa cosa? Come evitare che due persone modifichino lo stesso file? Come integrare il lavoro di tutti senza rompere nulla? In questa lezione metti insieme tutto ciò che hai imparato — branch, PR, review, Projects — e lo applichi a un progetto di gruppo reale. È la lezione che ti prepara al mondo del lavoro.
🎯 Obiettivi della lezione
- Organizzare un progetto di gruppo con ruoli e responsabilità
- Dividere il lavoro per ridurre i conflitti
- Seguire il workflow di team: branch → PR → review → merge
- Gestire i conflitti quando si verificano
- Fare code review tra compagni in modo costruttivo
- Usare la board Kanban per coordinare il lavoro
📖 1. Teoria
1.1 — Il setup del progetto di gruppo
Prima di scrivere una riga di codice, il team deve configurare il repository e stabilire le regole. 15 minuti di organizzazione iniziale salvano ore di caos dopo.
feature/nome), formato commit, chi revisiona chi.1.2 — Dividere il lavoro: la strategia per evitare conflitti
Il modo migliore per gestire i conflitti è evitarli. Due persone che modificano lo stesso file nello stesso momento creano conflitti. Due persone che lavorano su file diversi no.
index.html e style.css contemporaneamente → conflitti garantiti.
📌 I file condivisi (es. style.css globale) sono il punto critico. Se servono stili globali, create un file CSS condiviso che viene modificato solo dal “responsabile CSS” del team. Ogni pagina ha il suo CSS specifico. Questo riduce i conflitti sul file condiviso.
1.3 — Il workflow quotidiano del team
git pullgit nb feature/xsul tuo branch
compagno approva
Cancella branch
$ git sw main && git pl ← prendi le novità dei compagni
$ git nb feature/pagina-contatti ← crea branch dalla main aggiornata
# === Lavora ===
$ git ac “Aggiunta struttura HTML contatti”
$ git ac “Stile form e validazione”
$ git p ← push del branch
# === Apri PR su GitHub ===
# Titolo: “Aggiunta pagina contatti con form”
# Descrizione: cosa/perché/come testare. Closes #4
# Chiedi a un compagno di revisionare
# === Mentre aspetti la review: revisiona la PR di un compagno ===
# Vai nella sua PR → Files changed → lascia commenti → Approve
# === Dopo l’approvazione: merge ===
# Su GitHub: Merge pull request → Delete branch
# → La board sposta automaticamente l’issue in Done
1.4 — Gestire i conflitti nel team
Anche con una buona divisione del lavoro, i conflitti possono verificarsi. Non è un dramma — è una situazione normale. L’importante è saperli risolvere.
$ git sw feature/pagina-contatti ← vai nel tuo branch
$ git fetch origin
$ git merge origin/main ← integra le novità di main
CONFLICT (content): Merge conflict in style.css
# Apri il file in VS Code, risolvi i marker <<< === >>>
$ code style.css
# Dopo la risoluzione:
$ git add style.css
$ git commit -m “Risolto conflitto in style.css con main”
$ git push
# La PR su GitHub si aggiorna — i conflitti sono risolti
📌 Regola d’oro: chi ha il conflitto lo risolve. Se la tua PR ha conflitti, sei tu che devi aggiornare il branch e risolverli — non il reviewer e non il team leader. È il tuo branch, è la tua responsabilità.
1.5 — Code review tra compagni
Nel team, la review è reciproca: tu revisioni le PR dei compagni, loro revisionano le tue. È uno dei momenti più formativi — impari dal codice degli altri e migliori il tuo.
Giulia → revisiona Luca
Luca → revisiona Sara
Sara → revisiona Marco
Ogni PR ha esattamente 1 reviewer.
Più flessibile ma rischio che nessuno prenda l’iniziativa.
| Priorità | Cosa controllare | Esempio |
|---|---|---|
| 🔴 | Funziona? | Clona il branch, apri nel browser. Si rompe qualcosa? |
| 🟠 | È completo? | La feature fa tutto ciò che l’issue richiedeva? |
| 🔵 | È leggibile? | Nomi chiari? Commenti dove servono? Struttura logica? |
| 🟢 | Segue le convenzioni? | Indentazione, naming, struttura CSS coerente con il resto. |
1.6 — Usare la board per coordinare il team
1.7 — Problemi comuni nei team scolastici (e come risolverli)
| Problema | Soluzione |
|---|---|
| “Un membro non lavora” | La board lo rende visibile: la sua colonna “In Progress” è vuota da giorni. I commit hanno timestamp. Parlane subito con il team e il prof. |
| “Tutti pushano su main” | Branch protection (Lez. 20): push diretto su main bloccato. L’unico modo è via PR con review. |
| “Nessuno revisiona le PR” | Schema di rotazione fisso. Regola: revisiona entro 24 ore. La PR bloccata blocca il compagno. |
| “Conflitti ovunque” | Divisione del lavoro per pagina/componente. Pull e merge di main nel branch prima di ogni sessione. |
| “Non sappiamo chi fa cosa” | Board con issue assegnate. Ogni issue ha UN responsabile. Nessuna issue senza assegnatario. |
💻 2. Esempi guidati
Esempio A — Prima settimana di un progetto di team (4 studenti)
🏋️ 3. Esercizi
🟢 Esercizio 1 — Setup del progetto di team (Facile)
a) Uno crea il repository con README, .gitignore, LICENSE.
b) Aggiungi i compagni come collaboratori.
c) Attiva branch protection: PR obbligatoria + 1 approvazione.
d) Tutti clonano il repo. Verifica: tutti riescono a fare push su un branch (non su main)?
e) Crea il Project Board con le 4 colonne standard.
🔵 Esercizio 2 — Primo ciclo branch → PR → review → merge (Medio)
b) Ogni membro: prende la propria issue, crea un branch, lavora, committa, pusha, apre una PR con
closes #N.c) Schema di review a rotazione: ciascuno revisiona la PR del compagno assegnato.
d) Dopo l’approvazione: merge. L’issue si chiude automaticamente?
e) Tutti fanno
git pull su main. Il progetto ha i contributi di tutti?
🟠 Esercizio 3 — Gestire un conflitto reale (Medio)
a) Due membri creano branch diversi che modificano lo stesso file (es. entrambi modificano
style.css).b) Il primo fa merge della sua PR senza problemi.
c) Il secondo apre la PR: GitHub mostra “Conflicts”. Il merge è bloccato.
d) Il secondo membro risolve il conflitto (sezione 1.4): fetch → merge origin/main → risolvi marker → commit → push.
e) La PR si aggiorna. I conflitti sono risolti? Il merge ora funziona?
🟣 Esercizio 4 — Progetto di gruppo completo (Difficile)
a) Setup: repo, collaboratori, branch protection, Project Board, issue template, PR template.
b) Pianificazione: 8+ issue, milestone “v1.0”, assegnazioni, board popolata.
c) Sviluppo: ogni membro completa 2+ issue con il workflow branch → PR → review → merge.
d) Review: ogni PR ha almeno 1 review con commenti costruttivi (usa i prefissi della Lez. 18).
e) Consegna: milestone 100%, tag v1.0, release con notes, README completo, Pages online.
f) Retrospettiva: discussione (GitHub Discussions): “Cosa ha funzionato? Cosa miglioreremo la prossima volta?”
❓ 4. Quiz di verifica
1. Qual è il modo migliore per dividere il lavoro in un team e ridurre i conflitti?
Mostra risposta
Dividere per pagina o per componente, in modo che ogni persona lavori su file diversi. Se Mario fa la pagina Home (home.html, home.css) e Giulia fa la pagina About (about.html, about.css), non toccano mai gli stessi file e i conflitti sono quasi impossibili. La divisione per layer (uno fa HTML, uno CSS) è sconsigliata perché tutti toccano gli stessi file. Per i file condivisi (CSS globale, config), designa un solo responsabile.
2. La tua PR ha conflitti con main. Chi deve risolverli?
Mostra risposta
Tu — chi ha il conflitto lo risolve. È il tuo branch e la tua PR. Il procedimento: git fetch origin → git merge origin/main nel tuo branch → risolvi i marker di conflitto nel file → git add → git commit → git push. La PR su GitHub si aggiorna automaticamente e i conflitti spariscono. Non è compito del reviewer o del team leader risolvere i tuoi conflitti.
3. Perché la prima cosa da fare ogni mattina è git pull su main?
Mostra risposta
Perché i compagni potrebbero aver fatto merge delle loro PR da quando hai lavorato l’ultima volta. Se crei un nuovo branch da un main non aggiornato, il tuo branch parte da codice vecchio e avrà conflitti con le modifiche recenti. Il workflow corretto è: git switch main → git pull → git switch -c feature/nuova. Così il tuo nuovo branch parte dall’ultima versione di main che include il lavoro di tutti.
4. Un membro del team non lavora. Come lo rendi visibile?
Mostra risposta
La Project Board e la storia dei commit rendono il contributo di ciascuno trasparente. Se la colonna “In Progress” di qualcuno è vuota da giorni, se non ha commit nel repository, se non ha aperto né revisionato PR — è evidente. GitHub mostra anche il grafico dei contributi nella tab Insights → Contributors. Non servono accuse: i dati parlano. È un vantaggio del workflow Git: la trasparenza è automatica.
5. Come funziona lo schema di review a rotazione in un team di 4?
Mostra risposta
Ogni membro ha un reviewer fisso: A revisiona B, B revisiona C, C revisiona D, D revisiona A. Quando apri una PR, sai già chi deve revisionarla — non devi chiedere. Il reviewer ha la responsabilità di controllare entro un tempo concordato (es. 24 ore). Questo schema garantisce che tutti partecipino alla review e che nessuna PR resti bloccata in attesa. È più prevedibile della modalità “chi è libero” dove nessuno potrebbe prendere l’iniziativa.
6. Qual è la checklist di avvio di un progetto di gruppo?
Mostra risposta
5 passi: 1) Creare il repository con README, .gitignore, LICENSE. 2) Aggiungere i compagni come collaboratori e attivare branch protection (PR + 1 approvazione). 3) Creare il Project Board con 4 colonne (Backlog, Todo, In Progress, Done). 4) Creare le issue per tutte le parti del progetto e assegnarle. 5) Stabilire le convenzioni (naming branch, formato commit, schema review). 15 minuti di setup iniziale prevengono ore di confusione dopo.
📚 Riepilogo della lezione
- Checklist avvio: repo → collaboratori → protezioni → board → issue → convenzioni (15 min)
- Dividi per pagina/componente (file diversi) — non per layer (stessi file = conflitti)
- Workflow quotidiano: pull → branch → lavora → push → PR → review → merge
- Conflitti nella PR: chi ha il conflitto lo risolve → fetch → merge origin/main → risolvi → push
- Review a rotazione: schema fisso, entro 24 ore, usa i prefissi [blocking]/[suggestion]/[praise]
- La board rende tutto trasparente: chi fa cosa, chi è bloccato, chi non lavora
- Problemi comuni: branch protection previene push diretti, la board previene la disorganizzazione
Prossima lezione →
Lezione 34 — Portfolio su GitHub
Costruire la tua presenza professionale su GitHub.
Profilo, repository in evidenza, contributi, README del profilo.
Corso Git & GitHub · Per studenti e insegnanti · Lezione 33 di 45