Git 17
🔀 Git & GitHub · Modulo 3 · Lezione 17
Pull Request 🤝
Creare una PR · Descriverla · Richiedere review · Merge di una PR · Il cuore della collaborazione
🤝 La Pull Request è l’invenzione che ha reso GitHub rivoluzionario. Prima delle PR, integrare il codice significava: “ho finito, fai merge del mio branch”. Nessuna discussione, nessuna review, nessun controllo. Con le PR, l’integrazione diventa un processo: proponi le tue modifiche, le descrivi, qualcuno le revisiona, discutete, e solo dopo l’approvazione il codice entra in main. È il meccanismo che tiene la qualità alta in ogni progetto, dal più piccolo al più grande.
🎯 Obiettivi della lezione
- Capire cos’è una Pull Request e perché è meglio del merge diretto
- Creare una PR su GitHub
- Scrivere una buona descrizione con collegamento alle issue
- Richiedere una review ai compagni
- Fare merge di una PR su GitHub
- Conoscere le 3 opzioni di merge disponibili su GitHub
- Pulire il branch dopo il merge della PR
📖 1. Teoria
1.1 — Cos’è una Pull Request
Una Pull Request (PR) è una richiesta di integrare le modifiche di un branch in un altro — tipicamente da un feature branch a main. Ma non è un semplice merge: è un processo di revisione che avviene su GitHub con discussione, feedback e approvazione.
📌 Perché si chiama “Pull” Request? Il nome viene dalla prospettiva del maintainer: tu stai chiedendo a chi gestisce il repository di tirare (pull) le tue modifiche nel branch principale. Non stai facendo push in main — stai chiedendo il permesso di farlo. Questa inversione di controllo è ciò che rende le PR sicure.
1.2 — Il workflow completo con le PR
…commit…
git push -u origin feature/x
Titolo, descrizione, reviewer
Commenti, suggerimenti
Approvazione
git push
(la PR si aggiorna)
Le modifiche entrano in main
Issue collegata si chiude
git pull (locale)
git branch -d feature/x
1.3 — Creare una Pull Request su GitHub
Dopo aver pushato il tuo branch su GitHub, ci sono due modi per aprire una PR:
Closes #N. Usa Markdown per formattare.1.4 — Scrivere una buona descrizione di PR
(nient’altro)
Aggiunta validazione al form contatti.
## Perché
Closes #3 — il form si inviava vuoto.
## Come testare
1. Apri contatti.html
2. Lascia i campi vuoti
3. Clicca “Invia”
4. Deve mostrare errori rossi
## Checklist
– [x] Validazione email
– [x] Validazione nome
– [x] Messaggi di errore
– [ ] Test su mobile
1.5 — La pagina della PR: cosa vedi
Una volta aperta, la PR ha diverse sezioni che puoi esplorare:
| Tab | Cosa mostra | A cosa serve |
|---|---|---|
| Conversation | Descrizione, commenti, timeline degli eventi | Discussione generale sulla PR |
| Commits | Lista dei commit inclusi nella PR | Vedere la storia delle modifiche |
| Files changed | Il diff completo: tutte le righe aggiunte e rimosse | La tab più importante per il reviewer — il codice vero |
| Checks | Risultati dei test automatici (se configurati con Actions) | Verificare che il codice passi i test (Modulo 5) |
1.6 — Aggiornare una PR dopo i feedback
Se il reviewer chiede modifiche, non devi chiudere la PR e aprirne una nuova. Basta fare nuovi commit sul branch e pushare — la PR si aggiorna automaticamente.
$ git switch feature/validazione-form
$ echo “Messaggio inviato!” >> contatti.html
$ git add . && git commit -m “Aggiunto messaggio di successo dopo invio”
$ git push
1.7 — Fare merge della PR: le 3 opzioni
Quando la PR è approvata, il pulsante verde “Merge pull request” ha un menu a tendina con 3 opzioni:
| Opzione | Cosa fa | Risultato nel grafo | Quando usarlo |
|---|---|---|---|
| Create a merge commit ⭐ | Crea un merge commit con due genitori. Tutti i commit del branch restano nella storia. | Ramificato — si vede il “palloncino” del branch | Default. Conserva la storia completa. |
| Squash and merge | Combina tutti i commit del branch in un unico commit su main. | Lineare — un solo commit per tutta la feature | Quando il branch ha molti commit “WIP” che vuoi compattare. |
| Rebase and merge | Riappoggia i commit sopra main (come git rebase + fast-forward). |
Lineare — commit individuali ma senza merge commit | Quando vuoi storia lineare ma mantenere i commit separati. |
|\
| * commit C
| * commit B
|/
* commit A (main)
* commit A (main)
Un solo commit
* commit B’
* commit A (main)
Lineare, commit separati
📌 Quale scegliere? Per i progetti scolastici, “Create a merge commit” (default) va benissimo — conserva la storia completa e mostra chiaramente da quale branch proviene ogni modifica. “Squash and merge” è utile quando hai molti commit “WIP” e vuoi un main pulito. “Rebase and merge” è per chi vuole storia lineare senza merge commit. Nella maggior parte dei team, la scelta è fissata una volta per tutte nel repository.
1.8 — Dopo il merge: pulizia
# Dopo il merge, GitHub mostra un pulsante “Delete branch” — cliccalo.
# Oppure spunta “Automatically delete head branches” nelle Settings del repo.
# === SUL TUO COMPUTER ===
$ git switch main
$ git pull ← scarica il merge commit
$ git branch -d feature/validazione-form ← elimina il branch locale
# Se il branch remoto è stato cancellato su GitHub, pulisci i riferimenti:
$ git fetch –prune ← rimuove i tracking branch di branch remoti cancellati
1.9 — PR vs merge locale: quando usare quale
| Merge locale (git merge) | Pull Request su GitHub | |
|---|---|---|
| Dove avviene | Nel terminale, sul tuo computer | Su github.com, nel browser |
| Review | Nessuna — fai merge e basta | Revisione del codice integrata |
| Discussione | Nessuna | Commenti, suggerimenti, thread |
| Quando usarlo | Lavori da solo, esperimenti locali | Lavoro di team, progetti scolastici, open source |
💻 2. Esempi guidati
Esempio A — La tua prima Pull Request (passo per passo)
$ cd ~/Desktop/mio-progetto
$ git switch -c feature/pagina-about
$ echo “<h1>Chi siamo</h1><p>Siamo la classe 4A.</p>” > about.html
$ git add . && git commit -m “Creata pagina About con presentazione classe”
$ echo “a { color: navy; }” >> style.css
$ git add . && git commit -m “Aggiunti stili per i link nella pagina About”
# === PASSO 2: Push del branch ===
$ git push -u origin feature/pagina-about
## Cosa
Creata la pagina About con presentazione della classe e stili per i link.
## Come testare
Apri about.html nel browser e verifica che il testo sia visibile e i link siano in blu navy.
Closes #2Esempio B — Il reviewer approva e si fa merge
git switch main && git pull && git branch -d feature/pagina-about.Esempio C — Il reviewer chiede modifiche
🏋️ 3. Esercizi
🟢 Esercizio 1 — La tua prima PR (Facile)
feature/test-pr nel tuo repository su GitHub.b) Fai 1-2 commit (aggiungi o modifica un file).
c) Pusha il branch:
git push -u origin feature/test-pr.d) Su GitHub, apri una Pull Request verso main. Scrivi un titolo e una descrizione con almeno 3 righe.
e) Guarda le 3 tab della PR: Conversation, Commits, Files changed.
f) Fai merge cliccando “Merge pull request” → “Confirm merge”.
g) Cancella il branch su GitHub e poi in locale.
🔵 Esercizio 2 — PR con issue collegata (Medio)
b) Crea un branch con il numero:
feature/N-favicon.c) Lavora: aggiungi il file, fai 1-2 commit con
ref #N nei messaggi.d) Pusha e apri una PR. Nella descrizione, scrivi
Closes #N.e) Fai merge della PR.
f) Vai sull’issue: è stata chiusa automaticamente? Ci sono link ai commit e alla PR?
🟠 Esercizio 3 — PR con correzioni (Medio)
b) Nella PR, tu stesso lascia un commento nella tab “Files changed”: clicca il + accanto a una riga e scrivi “Qui dovrei aggiungere un commento nel codice”.
c) Torna nel terminale. Fai la modifica richiesta, committa e pusha.
d) Vai sulla PR: il nuovo commit è apparso? Rispondi al tuo commento: “Fatto!”.
e) Fai merge della PR. Quanti commit ha la PR in totale?
🟣 Esercizio 4 — Confronto delle 3 opzioni di merge (Difficile)
Questo esercizio ti fa provare tutte e 3 le opzioni di merge di una PR:
b) PR 1: fai merge con “Create a merge commit”.
PR 2: fai merge con “Squash and merge”.
PR 3: fai merge con “Rebase and merge”.
c) Dopo tutti e 3, fai
git pull in locale ed esegui git log --oneline --graph -n 15.d) Confronta i risultati nel grafo. Quale opzione produce un merge commit? Quale compatta i commit? Quale tiene i commit separati ma lineari?
e) Scrivi un paragrafo: quale opzione preferisci per il tuo progetto e perché?
❓ 4. Quiz di verifica
1. Cos’è una Pull Request e perché è meglio del merge diretto?
Mostra risposta
Una Pull Request è una richiesta di integrare le modifiche di un branch in un altro, con un processo di revisione integrato. È meglio del merge diretto perché aggiunge code review (qualcuno legge il codice prima dell’integrazione), discussione (commenti e suggerimenti documentati), e controllo qualità (approvazione obbligatoria, test automatici). Con il merge diretto, il codice entra in main senza che nessuno lo abbia controllato — con la PR, passa almeno un secondo paio di occhi. Questo riduce i bug e migliora la qualità del codice.
2. Come si aggiorna una PR dopo che il reviewer ha chiesto modifiche?
Mostra risposta
Basta fare nuovi commit sul branch e pushare. La PR si aggiorna automaticamente con i nuovi commit — non serve chiuderla e riaprirla. Il reviewer vede i commit aggiuntivi nella timeline della PR e può ri-revisionare il codice. Questo è uno dei vantaggi del design delle PR: il branch e la PR sono collegati, quindi qualsiasi push sul branch aggiorna la PR in tempo reale.
3. Qual è la differenza tra “Create a merge commit” e “Squash and merge”?
Mostra risposta
“Create a merge commit” mantiene tutti i commit del branch nella storia e crea un merge commit con due genitori — nel grafo si vede il “palloncino” del branch. “Squash and merge” combina tutti i commit del branch in un unico commit su main — nel grafo appare un solo commit lineare. Il primo conserva la storia dettagliata (utile per debug), il secondo produce una storia più pulita (utile quando il branch ha molti commit “WIP” poco significativi).
4. Se scrivi Closes #5 nella descrizione della PR, cosa succede quando la PR viene integrata?
Mostra risposta
L’issue #5 viene chiusa automaticamente quando la PR viene integrata in main. GitHub riconosce le parole chiave “Closes”, “Fixes” e “Resolves” seguite da un numero di issue. La chiusura avviene al momento del merge, non quando apri la PR. Nella timeline dell’issue appare un link alla PR, e nella PR appare un link all’issue — tutto è collegato. Puoi anche chiudere più issue con una sola PR: Closes #5, closes #7.
5. Dopo il merge della PR, cosa fai con il branch?
Mostra risposta
Lo cancelli, sia su GitHub che in locale. Su GitHub: clicca il pulsante “Delete branch” che appare dopo il merge (o attiva la cancellazione automatica nelle impostazioni del repository). In locale: git switch main, git pull (per scaricare il merge commit), git branch -d feature/x (cancella il branch locale). Opzionalmente: git fetch --prune per pulire i riferimenti ai branch remoti cancellati. I commit non vengono persi — sono raggiungibili da main tramite il merge.
6. Qual è la tab più importante per il reviewer in una PR?
Mostra risposta
“Files changed”. Questa tab mostra il diff completo di tutte le modifiche proposte dalla PR — ogni riga aggiunta (verde) e rimossa (rossa) in ogni file. Il reviewer può cliccare il + accanto a qualsiasi riga per lasciare un commento specifico su quel punto del codice. È qui che avviene la vera code review: il reviewer legge il codice, verifica la correttezza, suggerisce miglioramenti e segnala problemi. Le tab Conversation e Commits sono utili per il contesto, ma “Files changed” è dove si guarda il codice vero.
📚 Riepilogo della lezione
- Una Pull Request è una richiesta di merge con review, discussione e approvazione
- Workflow: branch → push → apri PR → review → (correggi) → merge → pulisci
- Buona descrizione: cosa, perché, come testare, closes #N
- Tab importanti: Conversation (discussione), Files changed (il codice, per la review)
- Aggiornare una PR: commit + push sul branch — la PR si aggiorna automaticamente
- 3 opzioni di merge: merge commit (storia completa) · squash (un commit) · rebase (lineare)
- Dopo merge: Delete branch su GitHub +
git pull+git branch -din locale git fetch --pruneper pulire i tracking branch di branch cancellati
Prossima lezione →
Lezione 18 — Code Review
Best practice per revisioni costruttive. Commenti inline e suggerimenti.
Approvazione e richiesta di modifiche. La cultura del feedback.
Corso Git & GitHub · Per studenti e insegnanti · Lezione 17 di 45