Cos'è una pull request nello sviluppo software?

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Configura branch protection, controlli CI e workflow di code review per team di prodotto negli USA e in Europa

Cos'è una pull request nello sviluppo software? È una richiesta formale di integrare un insieme di modifiche al codice da un branch a un altro — di solito da un feature branch di breve durata a main — dopo che altri ingegneri le hanno revisionate. Gli sviluppatori la abbreviano in «PR», e nella maggior parte dei team nulla arriva in produzione senza: nella PR convivono diff, motivazione, risultati dei test e discussione di review.

I team che gestiscono servizi di software product engineering su larga scala trattano la pull request come l'unico cancello che ogni modifica deve attraversare — review, test e controlli di sicurezza avvengono lì, non dopo il rilascio. Per questo la PR è uno dei punti più economici in cui trovare un bug, e uno dei più costosi in cui perdere tempo quando le review si bloccano.

La scala è enorme. Secondo il report Octoverse 2025 di GitHub, tra settembre 2024 e agosto 2025 gli sviluppatori hanno integrato in media 43,2 milioni di pull request al mese, il 23% in più rispetto all'anno precedente, con quasi un miliardo di commit inviati. Qui sotto trovate la definizione di pull request, il ciclo di vita completo, istruzioni passo per passo per crearne e revisionarne una, i tre metodi di merge, i workflow più diffusi, i benchmark 2026 e regole pratiche per la crescente ondata di PR generate dall'IA.

Cos'è una PR nello sviluppo software?

Una PR nello sviluppo software è una pull request: una proposta di integrare un branch di modifiche al codice in un altro branch, revisionata e approvata dal team prima del merge. La definizione di pull request in una frase: un pacchetto di modifiche revisionabile, discutibile e testabile che chiede ai responsabili di un branch di destinazione di accettarlo.

Una pull request confronta sempre due branch. Il branch head (detto anche sorgente o compare) contiene il nuovo lavoro; il branch base (la destinazione) è dove il lavoro deve arrivare, di solito main o develop. La piattaforma mostra la differenza come diff — righe aggiunte in verde, righe rimosse in rosso — e consente ai revisori di commentare ogni riga.

In una PR tipica intervengono tre ruoli. L'autore scrive il codice, apre la richiesta e risponde al feedback. Uno o più revisori leggono il diff, fanno domande, suggeriscono modifiche e approvano. Un maintainer o l'autore (una volta ottenute le approvazioni) esegue il merge. Le pull request vivono sulla piattaforma di hosting Git: GitHub, GitLab, Bitbucket e Azure DevOps implementano la stessa idea, come ricorda la panoramica di IBM sulle pull request, anche se i pulsanti hanno nomi diversi.

Cosa significa PR nello sviluppo software?

Nello sviluppo software PR significa pull request — non pubbliche relazioni. Il nome viene dal modello open source originale: un contributore senza permessi di scrittura inviava le modifiche alla propria copia e chiedeva al maintainer di tirarle dentro (to pull). Oggi l'autore spesso fa push nello stesso repository, ma il nome è rimasto. Gli ingegneri usano «PR» come sostantivo («aprire una PR»), come fase del workflow («è in PR») e come unità di lavoro («tre PR integrate oggi»).

Pull request e merge request

Pull request e merge request sono la stessa cosa con due nomi: GitHub, Bitbucket e Azure DevOps dicono «pull request», GitLab dice «merge request» (MR, richiesta di merge) perché l'azione finale è un merge. La documentazione di GitLab descrive le merge request come il luogo in cui proporre, revisionare e integrare modifiche al codice — esattamente il compito che altrove svolge una PR.

Come funziona una pull request?

Una pull request funziona come un ciclo breve: create un branch da main, fate commit delle modifiche, aprite una PR, lasciate che automazione e revisori la controllino, correggete ciò che emerge e fate il merge una volta approvata. Ogni PR nello sviluppo software segue più o meno gli stessi sette passaggi:

1. Creare un branch. Partite dal main più recente per isolare il vostro lavoro da quello degli altri.
2. Fare commit delle modifiche. Commit piccoli, raggruppati in modo logico, con messaggi chiari.
3. Fare push del branch. Caricatelo sul repository remoto condiviso (GitHub, GitLab, Bitbucket o Azure DevOps).
4. Aprire la pull request. Scegliete il branch base, scrivete titolo e descrizione, collegate il ticket e richiedete i revisori.
5. Eseguire i controlli automatici. La pipeline CI/CD compila il codice ed esegue unit test, linter, controlli dei tipi e scansioni di sicurezza; i risultati compaiono come status check sulla PR.
6. Revisionare e correggere. I revisori commentano e richiedono modifiche; l'autore fa push di nuovi commit sullo stesso branch e la PR si aggiorna automaticamente.
7. Approvare e integrare. Quando approvazioni e controlli richiesti sono verdi, la PR viene integrata nel branch base, il feature branch viene eliminato e la modifica prosegue verso il deploy.

Il concetto chiave è che la PR è un oggetto vivo. Ogni nuovo commit sul branch head aggiorna il diff, rilancia i controlli e segna come superati i commenti precedenti, così la discussione riflette sempre il codice attuale. Nulla tocca il branch base finché qualcuno non preme merge.

Anatomia di una buona pull request

Una buona pull request è piccola, mirata e autoesplicativa: un revisore deve capire cosa è cambiato, perché e come verificarlo senza chiedere all'autore. Nei nostri team una PR che rispetta questi sette punti viene di solito revisionata in giornata:

• Un titolo specifico. «Aggiungere retry con backoff all'handler del webhook di pagamento» batte «Fix bug».
• Una descrizione che risponde a cosa, perché e come testare. Due o tre brevi paragrafi o un template di PR compilato.
• Un ticket collegato. L'ID della issue o della story collega il codice al requisito di business e mantiene l'audit trail.
• Un diff piccolo. Un solo scopo per PR; refactoring e nuove funzionalità vanno in PR separate.
• Prove visive per le modifiche UI. Screenshot prima/dopo o una breve registrazione dello schermo.
• Una checklist completata. Test aggiunti, documentazione aggiornata, migrazioni reversibili, feature flag attivo — quello che chiede il vostro template di PR.
• I revisori e le etichette giuste. Un file CODEOWNERS richiede automaticamente il team responsabile; etichette come security o breaking-change indirizzano l'attenzione.

Come creare una pull request, passo per passo

Per creare una pull request fate push di un feature branch sul repository condiviso e aprite una PR verso il branch base, dall'interfaccia web o da riga di comando. Questa è la sequenza che usiamo su GitHub; GitLab, Bitbucket e Azure DevOps cambiano solo il nome dei pulsanti:

1. Aggiornare il main locale. Eseguite git checkout main e git pull per partire dal codice più recente.
2. Creare un feature branch. git checkout -b feature/payment-retry — con un nome descrittivo, legato al ticket.
3. Modificare e fare commit. git add . e poi git commit -m "Add exponential backoff to payment webhook". Mantenete i commit piccoli e significativi.
4. Fare push del branch. git push -u origin feature/payment-retry lo carica e imposta l'upstream.
5. Aprire la PR. Cliccate «Compare & pull request» nell'interfaccia web oppure eseguite gh pr create --base main --fill con la GitHub CLI.
6. Completare descrizione e revisori. Compilate il template, collegate il ticket, richiedete i revisori o lasciate che CODEOWNERS li assegni.
7. Scegliere bozza o pronta. Apritela come draft se volete feedback precoce o un passaggio di CI prima di finire il codice; segnatela «Ready for review» quando lo è.

Le draft pull request meritano di essere usate più spesso. Segnalano «guardate la direzione, non i dettagli», lasciano che la CI validi il branch mentre continuate a lavorare e non possono essere integrate per errore.

Come revisionare una pull request

Per revisionare una pull request leggete prima la descrizione, poi il diff, e verificate cinque aspetti: correttezza, test, leggibilità, sicurezza e prestazioni. Chiudete con uno di tre verdetti — commentare, approvare o richiedere modifiche. Una checklist pratica per il revisore:

• Correttezza. Il codice fa ciò che dicono descrizione e ticket, inclusi casi limite e percorsi di errore?
• Test. Il nuovo comportamento è testato, e i test fallirebbero se la modifica venisse annullata?
• Leggibilità e design. I nomi sono chiari, la logica è nel livello giusto, un nuovo collega capirebbe il codice?
• Sicurezza. Validazione degli input, controlli di autorizzazione, segreti, rischi di injection, nuove dipendenze.
• Prestazioni ed esercizio. Query N+1, cicli non limitati, indici mancanti, log e metriche per il nuovo percorso.

Indicate il peso di ogni commento. Un commento bloccante va risolto prima del merge; un nit («nit: rinominare in retryCount») è una rifinitura facoltativa. Le piattaforme supportano anche i suggested changes: il revisore scrive la riga sostitutiva esatta e l'autore la applica con un clic, eliminando un intero giro di scambi per le piccole correzioni.

La velocità conta quanto l'accuratezza. In «Modern Code Review: A Case Study at Google» (Sadowski et al., ICSE-SEIP 2018), basato su circa nove milioni di modifiche revisionate, la modifica mediana era di sole 24 righe, oltre il 35% delle modifiche toccava un solo file, l'attesa mediana del primo feedback era inferiore a un'ora per le modifiche piccole (circa cinque ore per quelle molto grandi) e la latenza mediana complessiva della review era inferiore a quattro ore. Modifiche piccole e primo feedback rapido vanno di pari passo.

Fare il merge di una pull request: merge commit, squash o rebase

Fare il merge di una pull request significa applicarne i commit al branch base, e GitHub offre tre metodi che differiscono solo per l'aspetto della cronologia risultante. Secondo la documentazione GitHub («About pull request merges»), un merge commit conserva tutti i commit e aggiunge un punto di merge esplicito, squash and merge combina tutti i commit in uno solo, e rebase and merge riapplica i commit uno per uno mantenendo una cronologia lineare.

Prima ancora che questi pulsanti funzionino, le regole di branch protection decidono se il merge è consentito: review approvate obbligatorie, status check obbligatori, conversazioni risolte e, facoltativamente, una merge queue che testa ogni PR sul branch base più recente prima di integrarla, così due PR verdi singolarmente non possono rompere main insieme.

Un conflitto di merge si verifica quando il branch base ha modificato le stesse righe toccate dalla vostra PR. Risolvetelo aggiornando il branch (git fetch e poi git rebase origin/main o git merge origin/main), sistemando i blocchi in conflitto, rieseguendo i test e facendo push. Le PR piccole e di breve durata vanno raramente in conflitto; quelle vecchie di una settimana quasi sempre.

I workflow di pull request usati dai team

I workflow di pull request definiscono come nascono i branch, quanto vivono e dove vengono integrati. La maggior parte dei team ne usa uno fra cinque, e la guida IBM alle pull request indica i primi quattro come gli schemi più comuni.

Feature branch workflow

Nel feature branch workflow ogni modifica ha il proprio branch creato da main e vi rientra tramite una pull request. È lo standard nella maggior parte dei team di prodotto: semplice da spiegare, facile da proteggere con regole di branch e ben supportato da ogni piattaforma.

Forking workflow

Nel forking workflow i contributori copiano l'intero repository nel proprio account, fanno push nel fork e aprono una pull request verso il progetto originale. I progetti open source si basano su questo modello, perché i contributori esterni non hanno mai bisogno di permessi di scrittura sul repository principale.

Git-flow

Git-flow usa branch di lunga durata main e develop più branch di feature, release e hotfix, ciascuno integrato tramite PR. È adatto a prodotti con rilasci pianificati e versionati — app mobili, software on-premise — ma aggiunge overhead ai team che fanno deploy in continuo.

Trunk-based development con PR di breve durata

Nel trunk-based development gli ingegneri integrano piccole PR in main almeno una volta al giorno, e le funzionalità incomplete restano nascoste dietro feature flag. I branch vivono ore, non settimane: i conflitti diventano rari e la continuous delivery ne beneficia.

Pull request impilate (stacked PR)

Le pull request impilate suddividono una funzionalità grande in una catena di piccole PR dipendenti, ciascuna basata sulla precedente. I revisori ricevono diff piccoli, l'autore va avanti senza attendere ogni review e la pila viene integrata in ordine.

Perché le pull request sono importanti: vantaggi per qualità del codice e team

Le pull request sono importanti perché pongono un unico checkpoint tracciato tra l'idea di uno sviluppatore e la produzione. I vantaggi principali:

• Gate di qualità. Bug, test mancanti e problemi di design emergono quando la correzione costa ancora poco.
• Condivisione della conoscenza. Almeno due persone comprendono ogni modifica, riducendo il rischio legato al «bus factor».
• Tracciabilità e audit trail. Chi ha cambiato cosa, chi l'ha approvato e perché resta registrato — le evidenze che gli auditor si aspettano per il change management SOC 2 e ISO 27001.
• Onboarding più rapido. I nuovi ingegneri imparano codebase e convenzioni del team leggendo e revisionando PR.
• Sicurezza shift-left. Controllo delle dipendenze, scansione dei segreti e analisi statica girano su ogni PR, non una sola volta prima del rilascio.
• Integrazione CI. La PR è il trigger naturale di build, test e ambienti di anteprima, e questi controlli sono il cuore della quality assurance nello sviluppo software.

Metriche delle pull request e benchmark 2026

Cinque metriche delle pull request mostrano se il vostro processo di review aiuta o frena la delivery: pickup time, tempo di review, cycle time, dimensione della PR e tasso di accettazione (di merge). Sono direttamente collegate ai KPI dello sviluppo software e alle metriche DORA come il lead time for changes.

• Pickup time — dall'apertura della PR (o dal momento in cui è segnata come pronta) alla prima attività di review.
• Tempo di review — dalla prima review all'approvazione o al merge.
• Cycle time — dal primo commit al merge o al deploy; pickup e review ne sono spesso le componenti maggiori.
• Dimensione della PR — righe modificate; il miglior predittore della durata di una review.
• Tasso di accettazione — la quota di PR aperte che vengono integrate entro una finestra stabilita.

Il LinearB 2026 Software Engineering Benchmarks Report, basato su 8,1 milioni di pull request di 4.800 team e 163.820 contributori in 42 Paesi, suddivide queste metriche in base a come è stato scritto il codice. I valori sono al 75° percentile; l'accettazione è il tasso di merge entro 30 giorni:

Usate questi numeri come riferimento, non come obiettivo. Monitorate le vostre mediane ogni settimana, osservate la tendenza e guardate prima il pickup time: di solito è il ritardo più facile da eliminare, perché è pura attesa.

Pull request generate dall'IA nel 2026: cosa cambia per i revisori

Le pull request generate dall'IA sono più grandi, aspettano più a lungo la review e vengono integrate molto meno spesso di quelle scritte da persone, quindi richiedono regole più severe, non più morbide. I benchmark LinearB 2026 mostrano PR assistite dall'IA di 408 righe contro 157 per quelle senza IA (75° percentile), pickup time di 8,3 ore per le PR assistite e 17,6 ore per quelle agentiche contro 3,4 ore senza IA, e un tasso di accettazione a 30 giorni del 32,7% per le PR di IA contro l'84,4% per quelle manuali. Anche nella fascia d'élite le PR manuali vengono accettate oltre il 95% delle volte e quelle di IA poco sopra il 71%.

Il fenomeno si spiega facilmente: i revisori esitano a prendere in carico un diff grande che nessuno nel team ha davvero scritto, e lo rifiutano quando l'intento non è chiaro. Queste sono le contromisure che applichiamo nei nostri team:

1. Limitare la dimensione. Lo stesso limite vale per PR di IA e umane; un agente che produce 1.000 righe deve suddividere il lavoro in una pila.
2. Richiedere test per ogni PR di IA. Nessun nuovo comportamento senza test che falliscono sul codice precedente.
3. Assegnare un responsabile umano. Ogni PR generata dall'IA ha un ingegnere nominato che risponde alle domande di review e risponde del merge.
4. Usare i bot di review IA come primo filtro. I revisori automatici individuano bene problemi di stile, bug evidenti e controlli null mancanti, ma l'approvazione finale resta a una persona che conosce il sistema.
5. Descrivere l'intento, non solo il risultato. La descrizione della PR deve spiegare il problema e l'approccio scelto, che il codice l'abbia scritto una persona o un agente.

Best practice per le pull request

La best practice più efficace è mantenere le pull request piccole e mirate; quasi tutte le altre servono a rendere queste PR piccole facili da revisionare e integrare in fretta. Sette regole che reggono con qualsiasi team e stack, a complemento delle più ampie best practice dello sviluppo software:

1. Mantenere le PR piccole. Una linea guida di team di circa 200–400 righe modificate funziona bene; la modifica mediana di 24 righe in Google (2018) e le 157 righe al 75° percentile delle PR senza IA di LinearB (2026) mostrano quanto siano piccole le PR sane.
2. Un solo scopo per PR. Non mescolate refactoring, aggiornamento delle dipendenze e funzionalità nello stesso diff.
3. Scrivere una descrizione chiara. Usate un template di PR con cosa, perché, come testare e rischi.
4. Aprire draft presto. Raccogliete feedback sulla direzione prima di investire nella rifinitura.
5. Automatizzare ogni controllo possibile. Formattazione, linting, test, controlli dei tipi e scansioni di sicurezza devono girare a ogni push, così i revisori si concentrano su logica e design.
6. Fissare uno SLA di review. Ad esempio prima risposta entro quattro ore lavorative e decisione entro un giorno lavorativo.
7. Risolvere tutte le conversazioni prima del merge. Attivate la regola nella branch protection, così nulla viene integrato con domande aperte.

Problemi comuni delle pull request e come risolverli

La maggior parte dei problemi delle pull request nasce da dimensioni e attese: le PR grandi aspettano di più, vanno più spesso in conflitto e ricevono review più deboli. I cinque problemi che vediamo più spesso, ciascuno con la sua soluzione:

• PR troppo grandi. I revisori le scorrono in fretta o le rimandano. Soluzione: suddividere per livello o usare PR impilate, e aggiungere un avviso sulla dimensione nella CI.
• Colli di bottiglia nella review. Un solo ingegnere senior revisiona tutto. Soluzione: distribuire la responsabilità con CODEOWNERS, far ruotare i revisori e monitorare il pickup time.
• Conflitti di merge. I branch di lunga durata si allontanano da main. Soluzione: integrare ogni giorno, fare rebase spesso e usare feature flag invece di branch lunghi.
• Approvazioni di facciata. «LGTM» dopo pochi secondi su un diff di 900 righe. Soluzione: PR più piccole, una checklist di review e l'approvazione obbligatoria di un code owner.
• PR abbandonate. Branch dimenticati intasano la coda. Soluzione: etichettare automaticamente le PR inattive da sette giorni e chiuderle o rilanciarle in un triage settimanale.

FAQ

Pubblicato il 7 ottobre 2026. Fonti: IBM Think, «What is a pull request?»; GitHub Docs, «About pull request merges»; GitHub Octoverse 2025; LinearB 2026 Software Engineering Benchmarks Report; Sadowski et al., «Modern Code Review: A Case Study at Google», ICSE-SEIP 2018; GitLab Docs, «Merge requests». I benchmark sono valori di riferimento; confrontateli con i dati del vostro team.