Cos'è una pull request?

Una pull request (PR) è un metodo per proporre modifiche a una codebase. Gli sviluppatori di software eseguono il fork del repository di codice principale (chiamato anche repository) in un ramo separato, eseguono il commit del codice su quel ramo mentre lavorano e creano una pull request per contrassegnare le modifiche suggerite per la revisione del codice prima di estrarre o unire le modifiche dal ramo alla codebase principale.

Le PR sono meccanismi comuni nei repository Git come Bitbucket e GitHub. GitLab utilizza il termine "merge request" anziché "pull request" per lo stesso processo.

Gli sviluppatori possono creare pull request utilizzando l'interfaccia a riga di comando (CLI) o l'interfaccia web. Le nuove pull request vengono in genere aperte per correzioni di bug, aggiornamenti delle dipendenze, nuove caratteristiche o codice sottoposto a refactoring. Le pull request semplificano le revisioni del codice, mantengono le codebase all'altezza degli standard e promuovono la collaborazione tra i membri dei team di sviluppo software.

Le PR permettono agli sviluppatori di creare codice sorgente e testarlo localmente. Poiché le modifiche al codice sono isolate dal ramo principale, gli sviluppatori non devono preoccuparsi di rompere l'intera codebase.

La metodologia delle pull request prevede tre ruoli vitali che si applicano principalmente ai progetti open source, ma possono essere adottati anche da progetti proprietari o closed-source:

• Manutentori: i manutentori del progetto gestiscono (e spesso possiedono) il progetto e hanno l'autorità di approvare e unire o rifiutare le PR.

• Revisori: questi membri del team (che possono essere a loro volta manutentori o altri contributori attivi con molta esperienza nel progetto) esaminano le modifiche proposte per la qualità del codice e suggeriscono miglioramenti secondo quanto ritengono.

• Contributori: questi sviluppatori hanno il compito di apportare modifiche e aprire pull request.

La creazione di pull request generalmente comporta un processo in sette fasi:

1. Un collaboratore effettua un fork del repository principale per creare un nuovo ramo (utilizzando git checkout tramite comando o interfaccia web) e clona questo ramo sulla propria macchina locale.
   
   
2. Il collaboratore lavora alle proprie modifiche e invia il codice localmente al ramo.
   
   
3. Una volta che il collaboratore ha terminato e testato il proprio codice, scarica innanzitutto gli ultimi aggiornamenti dal repository principale per evitare eventuali modifiche in conflitto prima di inviare il codice.
   
   
4. Il collaboratore apre una nuova pull request per integrare le modifiche proposte nel ramo principale.
   
   
5. I revisori ricevono notifiche quando le pull request vengono inviate. Controllano la PR per confrontare le differenze (note anche come diff) tra il ramo del collaboratore e il ramo principale, revisionando il codice e commentando le aree che necessitano di ottimizzazione o miglioramento.
   
   
6. I contributori effettuano ulteriori commit in base ai suggerimenti e alle richieste di modifica del revisore.
   
   
7. Quando tutte le modifiche sono state implementate, il revisore avvisa il manutentore, che approva la PR. La pull request viene quindi unita al repository principale.

I team di sviluppo software possono scegliere tra una serie di opzioni di workflow di PR a seconda delle loro esigenze. I workflow più comuni di pull request includono:

• Workflow basato su rami di caratteristiche

• Workflow con fork

• git-flow

• Workflow a stack

Ogni nuova caratteristica ha un proprio ramo dedicato con un nome descrittivo per evidenziare lo scopo della caratteristica. Una volta completata la caratteristica, gli sviluppatori possono spingere il ramo con la caratteristica nel ramo principale e creare una pull request.

Questo workflow mantiene la stabilità del ramo principale, poiché i contributori lavorano separatamente sulle caratteristiche. Ma la gestione di più rami di caratteristiche potrebbe diventare ingombrante.

La procedura in sette fasi descritta nella sezione precedente sulla creazione delle pull request corrisponde a un workflow con fork. I progetti open source spesso adottano questo workflow, che integra anche le pratiche di integrazione continua/fornitura continua (CI/CD). Il flusso di GitHub segue un processo simile al workflow con fork.

L'ingegnere informatico Vincent Driessen ha formulato git-flow nel 2010. Viene tipicamente usato per costruire software con calendari di rilascio rigorosi o per supportare varie versioni.

Questo workflow segue un modello di ramificazione composto da questi rami:

• main contiene l'ultima versione stabile

• develop funge da ramo di Integrazione per correzioni di bug, caratteristiche e altre modifiche al codice incluse nella prossima versione

• feature usa develop come ramo di sorgente e di destinazione, con le caratteristiche incorporate in develop quando sono pronte

• release è derivato da develop e contrassegnato con il numero di versione per la prossima versione, poi unito in develop e main una volta pronto per la spedizione

• hotfix viene derivato direttamente da main per correggere problemi di produzione ad alta priorità o gravità, e poi unito sia a develop che a main non appena le correzioni sono pronte

Gli sviluppatori creano pull request per i rami hotfix , feature e release che necessitano di revisione.

Un workflow suddivide le attività di grandi dimensioni in una sequenza di piccole modifiche incrementali al codice. La prossima modifica del codice dipende da quella precedente, quindi le pull request sono costruite l'una sull'altra.

Consideriamo una caratteristica che comporta modifiche a queste funzioni: il database o modello di dati, l'API e il front-end. Nel tradizionale workflow basato su rami di caratteristiche o con fork, un contributore deve attendere che la PR per le modifiche al database o al modello dati vengano revisionate, approvate e unite nel ramo principale prima di poter iniziare gli aggiornamenti dell'API. In un workflow a stack, questo periodo di attesa viene eliminato: il contributore può separarsi dalle modifiche al database o al modello dati per iniziare a lavorare sull'API, inviare una PR per quella e ramificare le modifiche API per affrontare i compiti frontend.

Le pull request offrono questi vantaggi:

• Promuovono la collaborazione

• Migliorano la qualità del codice

• Aumentano la trasparenza

• Rafforzano le competenze di codifica

Le pull request promuovono la cooperazione, incoraggiando i membri del team a lavorare insieme indipendentemente dal loro ruolo. Le PR facilitano i feedback e spiegano come affrontarlo, accendono discussioni e stimolano idee per migliorare.

Le PR avviano il processo di revisione del codice, aiutando a individuare bug, deviazioni dallo stile e dagli standard di codifica, problemi di prestazioni e vulnerabilità di sicurezza. Questa supervisione aggiuntiva mantiene o addirittura migliora la qualità del codice.

Le pull request consentono ai team di vedere quali modifiche sono state implementate, chi le ha apportate, dove sono state applicate e i motivi alla base. Tale visibilità fornisce una migliore insight dello stato della base di codice e del progetto stesso.

Sia revisori che contributori possono imparare l'uno dall'altro, acquisendo nuove tecniche lungo il percorso e scoprendo approcci innovativi ai problemi. I principianti e i nuovi membri del team possono anche studiare le PR precedenti per comprendere meglio la codifica e aggiornarsi sugli standard di codifica e le best practice del team.

Anche se la creazione di pull request sembra semplice, ecco alcuni suggerimenti e trucchi che possono facilitare ulteriormente il processo:

• Considera le bozze

• I dettagli contano

• Mantieni la concentrazione

• Rimani al passo con le novità

• Utilizza i modelli

Le bozze di pull request o merge request servono agli sviluppatori per condividere il loro lavoro in corso. Ciò consente ai membri del team di iniziare a collaborare prima e di ricevere feedback più tempestivamente, in modo che chi si trova in difficoltà possa trovare soluzioni collettive tra i propri membri del team.

Gli sviluppatori devono fornire messaggi chiari, concisi e specifici per i loro nuovi commit. Chiarezza, concisione e specificità si applicano anche ai titoli e alle descrizioni delle PR, rendendo più facile e veloce per i revisori cogliere l'intento dietro le modifiche al codice.

Raggruppare più issue in un'unica PR può comportare tempi di revisione più lunghi e più revisioni. Ogni pull request deve affrontare una sola correzione o caratteristica. Le pull request mirate possono portare a revisioni del codice più efficienti.

Prima di inviare codice e aprire una PR, gli sviluppatori devono assicurarsi che il loro ramo sia aggiornato. L'acquisizione delle ultime modifiche e di eventuali nuovi commit previene i conflitti una volta unita la pull request. Possono usare sia il comando git pull per recuperare e unire le modifiche dal ramo di destinazione o il comando git rebase per una cronologia pulita dei commit di git.

I modelli di descrizione delle PR aiutano a garantire la coerenza e a fornire un contesto fondamentale per semplificare le revisioni del codice. I team possono creare un modello per diversi tipi di pull request, come correzioni di bug, caratteristiche o codice sottoposto a refactoring.

I modelli sono solitamente scritti utilizzando il linguaggio di markup Markdown e collocati nella cartella principale o nel ramo principale del repository del progetto. I campi tipici includono:

• Descrizione del problema o delle caratteristiche (con un link al ticket corrispondente in Jira o altro software di tracciamento dei problemi come riferimento)

• Soluzione che illustra in dettaglio le modifiche al codice

• Test, come casi di test unitari o di integrazione, copertura dei test e passaggi per convalidare manualmente la soluzione, se applicabile

• Modifiche alla configurazione

• Elenco di controllo delle attività pertinenti, come la documentazione del codice e le build di codice pulite senza errori o avvisi

L'automazione delle PR può accelerare il ciclo di vita di una pull request dalla creazione alla revisione e all'unione. L'automazione delle PR comprende uno strato di sistemi che aiutano a ridurre i colli di bottiglia:

• PR in stack

• Pipeline CI/CD

• Sistemi di gestione SDLC

• Assistenti di codifica basati sull'AI

La maggior parte dei repository Git non è progettata per supportare un workflow a stack, ma alcuni strumenti astraggono la complessità della sincronizzazione delle pull request in stack e della gestione dei conflitti di merge. Questi strumenti includono la piattaforma Graphite, che ha una CLI e un'estensione per VS Code di Microsoft per le PR in stack e un'interfaccia web per gestirle; il sistema di gestione del codice sorgente Sapling di Meta; e la CLI open source ghstack per l'invio di differenze impilate a GitHub come pull request separate.

In quanto workflow DevOps automatizzato, la pipeline CI/CD contribuisce a garantire la qualità del codice. Piattaforme come GitHub Actions, GitLab e altri strumenti CI possono eseguire test unitari e test di integrazione e distribuire ambienti di anteprima che fungono da sandbox per visualizzare e testare le modifiche del codice nei PR.

Le pipeline CI/CD rafforzano anche le pratiche di codifica sicura. Gli analizzatori di codice statico e altri strumenti statici di test di sicurezza delle applicazioni (SAST) si integrano perfettamente con la maggior parte degli ambienti CI/CD per individuare le probabili vulnerabilità del codice. I team DevOps possono implementare hook pre-commit per il rilevamento dei segreti, rendendo la scansione segreta un passaggio obbligatorio prima che gli sviluppatori effettuino commit di codice o avviino pull request, bloccando modifiche che contengono segreti codificati.

Piattaforme come Jira e IBM Engineering Lifecycle Management (ELM) supportano il tracciamento e la gestione delle pull request durante tutto il ciclo di vita dello sviluppo software (SDLC).

Come parte della suite ELM, IBM Engineering Workflow Management (EWM) e IBM Engineering Integration Hub incorporano direttamente l'automazione PR nei workflow di sviluppo. EWM può connettersi con i repository Git tramite i connettori dell'Hub e attivare la creazione di PR dagli elementi di lavoro. Quando un requisito o una richiesta di modifica viene approvata in EWM, una regola può aprire automaticamente una pull request nel repository Git collegato e precompilare la descrizione.

Le automazioni basate su Al in ELM possono anche eseguire analisi statiche e suite di test una volta aperta la PR, postando i risultati nell'elemento di lavoro e bloccando l'unione fino al raggiungimento dei criteri. Nel frattempo, l'hub sincronizza lo stato delle PR tra gli strumenti, riflettendolo nel repository e nelle dashboard EWM per una visibilità in tempo reale.

Gli assistenti di codifica basati su AI come GitHub Copilot e IBM Bob possono aumentare i workflow delle pull request. Ad esempio, Bob può generare messaggi di commit ben formattati e significativi. Esamina il nome del ramo e la cronologia dei commit per farli corrispondere alle convenzioni di stile di un progetto.

Bob può anche creare una pull request direttamente dall'IDE di uno sviluppatore. Analizza il nome del ramo, le modifiche al codice e la cronologia dei commit per capire lo scopo e l'ambito. Genera quindi un titolo e una descrizione dettagliata della PR che riassume le modifiche, rilevando e utilizzando automaticamente i modelli PR esistenti di un progetto per le descrizioni delle pull request.