Perché usare una pull request invece di fare merge diretto?
Lo vediamo continuamente: sviluppatori che spingono codice direttamente su main o develop, senza passare da una pull request. Il problema? Puntualmente si rompe qualcosa — un conflitto non visto, una modifica che sovrascrive il lavoro di un collega, un errore di sintassi che manda in crash la produzione.
Noi, di Meteora Web, lavoriamo su progetti che vanno dal singolo sito WordPress a piattaforme Laravel con team distribuiti. La differenza tra un flusso ordinato e il caos è proprio la pull request. Non è burocrazia: è una rete di sicurezza che protegge il codice e risparmia ore di debugging.
Una pull request (PR) è una richiesta formale di unire le modifiche da un branch a un altro (di solito da feature a main). Il bello è che qualcun altro le osserva prima di accettarle. Questo si chiama code review. Non serve per fare la guardia: serve a migliorare la qualità, condividere conoscenza e prevenire incidenti.
Il costo di non usare le PR
Un cliente ci ha raccontato di aver perso un'intera giornata di lavoro perché due sviluppatori hanno modificato lo stesso file contemporaneamente su main. Senza branch separati e senza PR, l'unico modo per risolvere è stato un merge manuale con git log e conflitti da risolvere a mano. Tempo perso: 8 ore. Costo: centinaia di euro. Se avessero usato una PR con un branch feature, sarebbe bastato un click per vedere il conflitto e risolverlo prima del merge.
Sponsored Protocol
Regola pratica: se il tuo team è più di una persona, le PR non sono facoltative. Sono obbligatorie.
Come creare una pull request su GitHub?
Ci sono due modi: da terminale con GitHub CLI o dalla web UI. Partiamo dal terminale, perché è veloce e si integra con il flusso Git.
Usare GitHub CLI (gh)
Assicurati di avere gh installato e autenticato. Poi, dopo aver pushato il tuo branch:
git checkout -b fix/login-bug
git add .
git commit -m "Corregge bug nel login"
git push origin fix/login-bug
gh pr create --title "Corregge bug login" --body "Risolve il problema del redirect dopo login. Fix #42" --base main
Il flag --base indica il branch di destinazione. Senza, usa quello di default (di solito main).
Dalla web UI di GitHub
Dopo aver pushato il branch, su GitHub trovi un banner giallo che ti invita a creare una PR. Clicchi, compili titolo e descrizione, selezioni revisori e label, poi clicchi Create pull request.
Consiglio: la descrizione della PR dovrebbe includere il perché della modifica, non solo il cosa. Un esempio: "Abbiamo spostato la validazione lato server perché il client non era affidabile. Questo riduce i falsi positivi e velocizza il form." Più contesto dai, più facile sarà la review.
Sponsored Protocol
Collegare issue e progetti
Puoi collegare una PR a un issue GitHub scrivendo Closes #42 nel body. Alla chiusura della PR, l'issue viene automaticamente chiuso. Questo è utilissimo per tenere traccia del lavoro.
Come fare code review in modo efficace?
La code review non è un esame. È una conversazione tecnica. Obiettivo: trovare bug, migliorare leggibilità, verificare che il codice segua gli standard del team.
Il flusso di review su GitHub
Quando ricevi una richiesta di review:
- Apri la PR e clicca su Files changed.
- Leggi il codice riga per riga. Non serve recensire tutto se la PR è enorme: chiedi prima di dividerla in PR più piccole.
- Aggiungi commenti sulle righe dove vedi problemi: clicca sul numero di riga e scrivi.
- Al termine, scegli una azione: Comment (solo osservazioni), Approve (ok per il merge), Request changes (blocca fino a correzioni).
- Se chiedi modifiche, lo sviluppatore fa commit aggiuntivi sul branch. La PR si aggiorna automaticamente. Poi tu rileggi.
Checklist per una review efficace
- Il codice risolve il problema descritto?
- Ci sono test? Se mancano, è un warning.
- La logica è chiara? Nomi di variabili e funzioni auto-esplicativi?
- Ci sono vulnerabilità (SQL injection, XSS, hardcoded password)?
- Il codice segue le convenzioni del progetto (indentazione, nomi, struttura)?
- Ci sono commenti che spiegano perché una scelta è stata fatta?
Noi usiamo una semplice regola: nessuna PR deve rimanere aperta più di 24 ore. Se il team è piccolo, si fa una review al giorno. Se è grande, si assegna un revisore a rotazione. Le PR vecchie finiscono per creare conflitti e rallentare il rilascio.
Sponsored Protocol
Cosa sono le regole di protezione del branch e come configurarle?
La protezione del branch è il meccanismo che impedisce modifiche dirette su main (o altri branch sensibili). È il complemento obbligatorio delle PR. Senza protezione, qualcuno può bypassare la review e spingere codice direttamente.
Configurare la protezione su GitHub
Vai su Settings del repository → Branches → Add branch protection rule. Inserisci il nome del branch (ad esempio main). Poi seleziona:
- Require a pull request before merging — obbliga l'uso delle PR per qualsiasi modifica.
- Require approvals — imposta il numero minimo di approvazioni (tipicamente 1 o 2).
- Dismiss stale pull request approvals when new commits are pushed — se fai un commit dopo l'approvazione, la review decade. Utile per sicurezza.
- Require status checks to pass before merging — collega a CI/CD (es. test automatici, linting).
- Restrict who can dismiss pull request reviews — solo owner o admin.
- Do not allow bypassing the above settings — blocca anche admin (se vuoi).
Un esempio pratico: su un progetto Laravel che gestiamo, abbiamo attivato: PR obbligatoria, 1 approvazione, test automatici con GitHub Actions. Il branch main è blindato. Nessuno può spingere direttamente, nemmeno noi admin (tranne in emergenza con override). Questo ha ridotto i merge accidentali a zero.
Sponsored Protocol
Protezione per più branch
Puoi applicare la stessa regola a develop, release/*, ecc. Usa pattern come release/* per coprire tutti i branch di rilascio.
Automazioni con GitHub Actions
Oltre alla protezione statica, puoi aggiungere workflow automatici che eseguono test, analisi statica (PHPStan, ESLint) e deploy. Un esempio minimo per eseguire test su ogni push verso un branch di feature:
name: CI
on:
pull_request:
branches: [ main ]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install && npm test
Con questo, la PR non può essere mergiata finché il job test non passa (se attivi Require status checks).
Sponsored Protocol
Cosa fare adesso
Se il tuo repository non ha ancora branch protection, ecco tre azioni immediate:
- Proteggi il branch principale: vai su Settings → Branches e aggiungi una regola per main: PR obbligatoria, almeno 1 approvazione.
- Inizia a usare le PR per ogni modifica: anche per fix banali. Prendi l'abitudine: branch feature, push, PR, review, merge. Dopo una settimana diventa automatico.
- Inserisci una checklist di review: stampala o tienila in un Google Doc per il team. Ci aiuterà a non dimenticare i punti critici.
Noi, di Meteora Web, vediamo ogni giorno team che passano dal caos a un flusso ordinato con poche regole ben applicate. La pull request non è un ostacolo: è il tuo miglior alleato per scrivere codice migliore, più sicuro e condiviso. Se vuoi approfondire il quadro completo di Git per team, dai un'occhiata alla nostra guida principale su Git per sviluppatori — dalle basi ai workflow team.
Ricorda: un repository protetto è un repository che non ti farà perdere sonno.
