GitHub introduce le stacked pull request: ecco come funzionano

Le cosiddette pull request accompagnano GitHub fin dai primi mesi di vita della piattaforma: la prima implementazione risale al 2008, mentre nel 2010 arrivò un’interfaccia più vicina al modello di revisione del codice di programmazione usato oggi. Da allora sono diventate il punto di passaggio abituale per discutere modifiche, eseguire test automatici e decidere cosa integrare nel ramo principale.

La crescita degli strumenti di generazione del codice, però, ha reso più evidente un vecchio problema: le modifiche troppo grandi rallentano la revisione e aumentano la probabilità che un dettaglio importante sfugga. GitHub prova ora ad affrontarlo con le stacked pull request, disponibili in anteprima pubblica dal 30 luglio 2026.

Il dato citato da GitHub aiuta a capire la portata della questione: circa il 30% delle pull request ospitate dalla piattaforma modifica più di 20 file e l’arrivo degli assistenti di programmazione ha ulteriormente accelerato la produzione di codice. GitHub riferisce che Copilot Code Review ha già elaborato oltre 60 milioni di revisioni e partecipa a più di una revisione su cinque. Il collo di bottiglia, in pratica, si sta spostando dalla scrittura alla verifica.

Che cosa sono le stacked pull request di GitHub

Una stack è una sequenza ordinata di pull request dipendenti. Ogni elemento contiene una modifica circoscritta e usa come base il ramo collocato immediatamente sotto, non necessariamente main. Solo il primo livello della catena punta direttamente al ramo principale.

Immaginiamo una funzione composta da tre parti: prima il modello dati, poi le API e infine l’interfaccia. Con il metodo tradizionale lo sviluppatore potrebbe creare una sola pull request contenente tutto. Con le stacked pull request prepara invece tre rami concatenati: feature-model deriva da main, feature-api deriva da feature-model e feature-ui parte da feature-api.

GitHub associa una pull request a ciascun ramo e mostra al revisore soltanto le differenze relative a quello specifico livello. Chi esamina le API, quindi, non deve rileggere anche le modifiche al modello già presenti nel ramo sottostante.

Perché una grande pull request è difficile da revisionare

Una pull request estesa non richiede soltanto più tempo. Costringe chi legge a mantenere in memoria molte relazioni contemporaneamente: quali file appartengono alla stessa modifica, quali righe rappresentano semplice riorganizzazione e quali introducono un nuovo comportamento. Dopo alcune centinaia di righe, la revisione rischia di trasformarsi in una verifica superficiale del risultato generale.

Spezzare il lavoro in blocchi logici riduce il carico cognitivo: un livello può introdurre i tipi e le strutture dati, quello successivo la logica applicativa, un altro ancora i test o l’interfaccia. Ogni pull request conserva una motivazione riconoscibile e può ricevere commenti mirati.

Le stack possono anche favorire il lavoro parallelo: mentre un revisore controlla il primo livello, un altro può esaminare una modifica superiore; lo sviluppatore, nel frattempo, continua a lavorare senza aspettare che ogni passaggio precedente raggiunga main.

GitHub cita l’esperienza dei team Next.js, TED e WHOOP, che durante la fase di test hanno usato questa impostazione per implementare funzionalità ampie attraverso modifiche più piccole e leggibili.

Una risposta concreta al codice prodotto più velocemente

Le stacked pull request non migliorano automaticamente la qualità del software. Una suddivisione mal progettata può frammentare la discussione, nascondere dipendenze importanti o costringere i revisori a saltare continuamente tra livelli diversi. Serve disciplina: ogni stacked pull request dovrebbe avere uno scopo riconoscibile, test pertinenti e una descrizione che chiarisca il ruolo occupato nella catena.

L’integrazione nativa elimina però una parte considerevole del lavoro meccanico: GitHub gestisce le basi delle pull request, mostra l’ordine dei livelli e consente di fondere porzioni contigue senza ricostruire manualmente i rami rimasti.

GitHub non sta soltanto aggiungendo un’altra modalità di merge: riconosce che la quantità di codice prodotta sta crescendo più rapidamente della capacità umana di esaminarlo. Rendere le modifiche più piccole e ordinate non risolve ogni problema, ma restituisce al revisore un’unità di lavoro comprensibile. E oggi, con agenti capaci di generare intere funzionalità in pochi minuti, è forse l’aspetto più prezioso.