GitHub stacked PR: un diff piccolo non è un'unità di rilascio
Tre PR accorciano la lettura di una modifica grande. Se quella superiore dipende dall'inferiore, non diventa automaticamente distribuibile da sola.
L'annuncio del 6 ottobre
GitHub ha annunciato la disponibilità generale il 6 ottobre 2026. Le PR mirate si possono rivedere separatamente e unire insieme, su tutti i piani github.com.
Uno stack entra nella merge queue come un merge group. Il metodo merge commit crea invece un commit per PR. Unità testata e unità della cronologia sono diverse.
Scrivere il confine di revisione
A aggiunge una funzione, B la usa in un'API, C crea la UI. Indicate dipendenze e base del confronto. È un metodo consigliato, non una garanzia automatica del prodotto.
Leggere solo B può nascondere un controllo di autorizzazione mancante in A. Separate revisione del diff e verifica A+B+C, assegnando un responsabile dell'integrazione.
Approvazioni dopo rebase
GitHub mantiene le approvazioni quando uno stack altrimenti invariato viene ribasato dopo il movimento della base, anche con invalidazione delle vecchie approvazioni. Approvazione e prova d'integrazione restano distinte.
Registrate SHA prima e dopo e merge group testato. Controllate nuove esecuzioni e combinazione coperta dai log: una spunta verde non basta.
Separare merge e deployment
Se funzione e API devono uscire insieme, conservate la dipendenza nel piano. Un commit per PR non rende sicuro il rollback isolato se rimangono chiamanti incompatibili.
I bug fix indipendenti non richiedono uno stack. Raggrupparli può far attendere tutti per un solo test in ritardo: valutate il costo operativo.
GA e disponibilità effettiva
GitHub prevede auto-merge nelle settimane successive. Verificate i controlli visibili nel repository prima di supporre lo stesso pulsante per ogni account.
Il feedback della preview ha orientato miglioramenti di navigazione e automazione. Indica interesse, non produttività garantita. Misurate attese di revisione e fallimenti d'integrazione.
Provare uno stack piccolo
Scegliete due PR con dipendenza chiara, come funzione e chiamante. Documentate base, dipendenza e test, concordando responsabile e perimetro del rollback.
Confrontate tempo risparmiato e nuovi errori. Se mantenerlo costa di più, tornate alle PR normali. Conta la chiarezza di revisione e distribuzione, non il numero di diff.
Fonti ufficiali
Annuncio del 6 ottobre; verifica dell'8 ottobre 2026. Controllate regole e funzioni prima dell'adozione.