Revisiona la tua prima pull request

Cosa costruirai

Alla fine di questo tutorial avrai:

• Aperto una pull request nel banco di lavoro delle PR di Control Center
• Letto il suo diff e lasciato un commento inline
• Inviato un verdetto di revisione
• Unito la PR

Prerequisiti: Invia il tuo primo agente completato e una pull request aperta su un repo registrato in questo spazio di lavoro. Per i passaggi di revisione, scegli una PR che non hai aperto tu — il pulsante Revisione è nascosto sulle tue PR. Merge funziona comunque su una PR di cui sei l’autore.

Passaggio 1: apri la pull request

1. Fai clic su Pull request nella barra laterale
2. Trova la tua PR e fai clic su di essa

Checkpoint. La PR si apre come un banco di lavoro a schede — Panoramica, Diff, Controllo del codice, Chat, Azioni — incentrato su Panoramica: titolo e azioni, descrizione e cronologia dell’attività, più una barra laterale con stato, revisori, assegnatari, controlli e file modificati. Facendo clic su un file lì, si passa direttamente a quel file nella scheda Diff. La scheda Revisione PR non è aperta finché qualcuno non richiede una revisione IA.

Coda vuota con un invito a collegare GitHub

Quello stato significa che il server non detiene alcun token GitHub — il tuo client non ne detiene mai uno. Impostane uno in Impostazioni → Spazio di lavoro → Profilo e identità → Hosting del codice, poi aggiorna l’elenco.

Passaggio 2: leggi il diff

Apri la scheda Diff. Un albero dei file comprimibile si trova a sinistra, e la striscia sopra il diff contiene un selettore dell’intervallo di commit — per restringere il diff a un commit o a una serie di commit — oltre al numero di file e al conteggio progressivo delle aggiunte e delle rimozioni.

Il pulsante delle impostazioni nella barra degli strumenti del diff ne controlla la resa:

• Vista Affiancata o Unificata
• A capo automatico o scorrimento delle righe lunghe
• Legature del font del codice

Contrassegna un file come visto per seguire i tuoi progressi in un diff di grandi dimensioni. La navigazione da tastiera è descritta in Scorciatoie da tastiera.

Passaggio 3: lascia un commento inline

1. Passa il mouse sopra una riga del diff — nel margine compare una piccola pillola +
2. Fai clic su di essa per commentare quella riga, oppure trascinala prima verticalmente per selezionare un intervallo
3. Digita il tuo feedback. Il composer offre due invii:
   • Avvia una revisione (o Aggiungi alla revisione se una revisione è già in corso) mette in coda il commento. Il thread mostra Revisione in sospeso finché non invii un verdetto al passaggio 4.
   • Aggiungi un solo commento lo pubblica subito su GitHub. Il thread mostra Pubblicazione…, poi Sincronizzato, e offre un nuovo tentativo se la pubblicazione fallisce.

Per questo tutorial, usa Avvia una revisione in modo che il commento esca insieme al verdetto.

Un commento in coda non è ancora su GitHub

Avvia una revisione / Aggiungi alla revisione tengono il commento in locale finché non invii un verdetto. Solo Aggiungi un solo commento pubblica immediatamente. Il corpo della revisione che scrivi al passaggio 4 è una bozza separata.

Passaggio 4: invia una revisione

1. Fai clic su Revisione nella riga delle azioni della Panoramica — lo stesso pulsante si trova anche nella barra degli strumenti della scheda Diff. È nascosto sulle PR di cui sei l’autore e su una PR chiusa o unita.
2. Scrivi un riassunto nel composer. Viene salvato automaticamente come bozza, così puoi chiudere l’overlay e tornarci.
3. Scegli un verdetto:
   • Richiedi modifiche
   • Commenta
   • Approva

Il verdetto è il pulsante. Dopo Approva o Richiedi modifiche, il pulsante si rinomina in Approvato o Modifiche richieste. Un verdetto Commenta lo lascia etichettato Revisione.

Checkpoint. Il pulsante mostra «Approvato» o «Modifiche richieste» se hai scelto uno dei due.

Passaggio 5: unisci

Il pulsante Merge è presente ogni volta che GitHub segnala che la PR è unibile — non è vincolato alla tua approvazione. Il suo colore indica la preparazione anziché un permesso: primario quando le approvazioni richieste e i controlli sono verdi, secondario mentre un controllo è ancora in esecuzione, distruttivo quando un revisore richiesto non ha approvato o un controllo sta fallendo.

1. Fai clic su Merge
2. Scegli un metodo: Squash and merge, Create a merge commit o Rebase and merge
3. Per i primi due, modifica il titolo e il messaggio del commit precompilati
4. Conferma

Gli eventuali problemi in sospeso — «Controlli falliti», «Some reviews are pending» — sono elencati nel pannello a comparsa prima che tu confermi.

L’unione è irreversibile

L’unione invia commit a GitHub. Non entra mai nello stack di annullamento di Control Center e non può essere annullata da qui.

Dopo l’unione, viene emesso un evento di dominio PrMerged; le analisi e le notifiche lo consumano. Vedi Eventi di dominio per sapere cos’altro è in ascolto.

Revisionare con l’IA

Control Center può mettere una pipeline di revisori su una PR aperta, ma solo quando lo chiedi: il modello pr_review ha un trigger manuale e nulla di più.

1. Apri il menu a comparsa ⋯ nella riga delle azioni della Panoramica e scegli Ask AI. Control Center avvia l’esecuzione e apre la scheda Revisione PR, così puoi guardare gli specialisti al lavoro.
2. Gli agenti revisori registrano i loro rilievi come nodi di revisione nello spazio della PR; un passaggio finale li consolida in un unico report.

La pipeline di proposito non pubblica su GitHub — termina dopo la consolidazione. La pubblicazione è un passaggio separato che compi tu stesso, con il pulsante Pubblica su GitHub nella scheda Revisione PR. Vedi Usa la revisione basata sull’IA.

Riepilogo

Hai aperto una PR nel banco di lavoro, letto il diff con l’evidenziazione della sintassi, lasciato un commento inline, inviato un verdetto e unito — senza uscire dall’app.

Avanti: Crea la tua prima pipeline per automatizzare workflow a più passaggi.