Skip to main content
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.
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.

​
Come funziona uno stack

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.

​
Quando Devin crea uno stack

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.

​
Mantenere coerente lo stack

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.

​
Lavorare con gli stack

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.

​
Revisione e merge degli stack

Devin Review 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.

​
Limitazioni

  • 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.