> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PR impilate

> Come Devin suddivide modifiche di grandi dimensioni in pile ordinate e revisionabili di pull request

Quando un'attività è troppo grande per essere revisionata agevolmente come un'unica PR, Devin può suddividerla in uno **stack**: una serie ordinata di pull request che compongono un unico lavoro e vengono integrate insieme, dal basso verso l'alto. Ogni PR dello stack è una PR normale e mirata, basata su quella sottostante: i revisori esaminano una piccola modifica autonoma alla volta anziché un unico diff monolitico.

Gli stack di Devin si basano sulle pull request impilate native di GitHub, quindi uno stack è un oggetto GitHub di prima classe, non una convenzione basata sui nomi dei branch.

<Note>
  Le PR impilate sono supportate **solo per i repository su GitHub.com**. GitHub
  Enterprise Server, GitLab e altri provider non dispongono di un'API per le PR impilate.
</Note>

<div id="how-a-stack-works">
  ## Come funziona uno stack
</div>

Uno stack è una serie di patch:

* Le pull request sono ordinate dal basso verso l'alto. La PR più in basso è rivolta al branch trunk (ad es. `main`); il branch di base di ogni altra PR è il branch head della PR immediatamente sotto.
* Poiché ogni PR viene confrontata con il livello sottostante, mostra solo le proprie modifiche, senza includere nulla dai livelli sopra o sotto.
* Lo stack viene integrato dal basso verso l'alto. Il merge di una PR nello stack integra anche tutte le PR aperte sottostanti, in modo atomico e in un'unica operazione. Man mano che le PR inferiori vengono integrate, GitHub reindirizza automaticamente le PR rimanenti al branch trunk.

<div id="when-devin-creates-a-stack">
  ## Quando Devin crea uno stack
</div>

Devin crea stack in modo intenzionale, non opportunistico. Crea uno stack solo quando ha deliberatamente suddiviso un'attività in una serie ordinata di PR pensate per essere integrate insieme — ad esempio, una modifica allo schema, poi il livello di servizio che la utilizza e infine l'interfaccia utente soprastante. Le PR che si basano semplicemente sul branch di un'altra PR non vengono raggruppate in uno stack.

Quando Devin pianifica uno stack:

1. **Annuncia lo stack** per nome prima di creare qualsiasi PR, così puoi vedere la serie prendere forma nella tua sessione.
2. **Crea ogni PR** come una normale PR mirata — con la propria descrizione e la propria CI — ciascuna con il branch head della PR sottostante come destinazione.
3. **Raggruppa le PR in uno stack** su GitHub una volta create.

Ogni livello deve rispettare gli stessi standard di qualsiasi PR autonoma rilasciata da Devin: un diff minimo e mirato e una descrizione ricca di informazioni, scritta per un revisore che non ha visto il codice.

<div id="keeping-the-stack-coherent">
  ## Mantenere coerente lo stack
</div>

Uno stack non è immutabile una volta creato. Devin rimane associato a ogni PR dello stack per tutta la durata della sessione:

* **Risoluzione dei conflitti** — Se un livello genera conflitti di merge con il branch sottostante (ad esempio, dopo l'applicazione di feedback di revisione a un livello inferiore o quando il trunk avanza sotto lo stack), Devin riceve automaticamente una notifica e risolve i conflitti senza intervento. Ti chiede conferma solo quando un conflitto comporta una decisione sostanziale che richiede il tuo contributo.
* **CI nell'intero stack** — Devin monitora la CI per ogni livello e corregge gli errori non appena si presentano, tenendo traccia dello stato di avanzamento dell'intera serie anziché seguire le PR una alla volta.
* **Riassegnazione automatica della destinazione** — Man mano che la base dello stack viene integrata, GitHub reindirizza le PR rimanenti al trunk. Non è necessario gestire manualmente i rebase.

<div id="working-with-stacks">
  ## Lavorare con gli stack
</div>

Puoi gestire il comportamento degli stack di Devin in una sessione:

* Chiedi a Devin di suddividere una modifica di grandi dimensioni in uno stack oppure di mantenere il lavoro in un'unica PR.
* Chiedi a Devin di aggiungere PR successive in cima a uno stack esistente.
* Chiedi a Devin di verificare lo stato di uno stack: verranno riportati lo stato di ogni livello, la CI, l'esito della revisione e la possibilità di merge.
* Chiedi a Devin di **unstack**: lo stack viene sciolto e le PR non ancora sottoposte a merge tornano a essere PR indipendenti, con i relativi branch lasciati invariati. I livelli già sottoposti a merge restano tali.

Nella vista della sessione, le PR che appartengono a uno stack mostrano la relativa appartenenza e gli stack annunciati vengono visualizzati prima ancora che esistano le relative PR, così puoi seguire Devin mentre crea la serie.

<div id="reviewing-and-merging-stacks">
  ## Revisione e merge degli stack
</div>

[Devin Review](/it/work-with-devin/devin-review#stacked-prs) considera gli stack elementi di prima classe: l'intera serie è visibile a colpo d'occhio, con lo stato di avanzamento di ogni livello, e il merge avviene in modo atomico dal basso verso l'alto. Per maggiori dettagli, consulta la [sezione sulle PR impilate della documentazione di Devin Review](/it/work-with-devin/devin-review#stacked-prs).

<div id="limitations">
  ## Limitazioni
</div>

* **Solo GitHub.com** — gli stack non sono disponibili su GitHub Enterprise Server, GitLab, Bitbucket o Azure DevOps.
* **Dimensioni dello stack** — uno stack contiene da 2 a 100 PR.
* **Merge** — le PR impilate non possono essere unite tramite il normale flusso di merge di GitHub; vengono unite tramite il merge dello stack, che integra la PR selezionata e tutte le PR aperte sottostanti in un'unica operazione.