Pull request in Git: la tua guida su come funziona

Le pull request hanno aiutato i miei team a evitare bug, allinearci sulle decisioni di implementazione e imparare dal codice degli altri. In questa guida ti mostrerò come usare le pull request sulle piattaforme basate su Git per rivedere il tuo codice in sicurezza.

Se stai iniziando con Git, ti consiglio di seguire i nostri corsi Introduction to Git e Introduction to GitHub Concepts per imparare il controllo versione e le differenze tra Git e GitHub. Inoltre, trovo che il Git Cheat Sheet, che puoi scaricare, sia un’utile riferimento perché raccoglie tutta la terminologia e i comandi Git più comuni.

Che cos’è una pull request?

Una pull request è in sostanza un modo per proporre modifiche al codice. Immagina che tu stia lavorando a una funzionalità o in un branch separato: una pull request ti permette di chiedere di unire quelle modifiche alla codebase principale, di solito dopo che altri hanno avuto modo di rivederle. Le pull request sono una parte fondamentale dello sviluppo collaborativo, soprattutto quando si lavora in team.

Vale la pena notare che su GitLab lo stesso processo si chiama “Merge Request”. 

Come funziona una pull request?

I passaggi seguenti descrivono il workflow di base di una pull request:

1. Apporta modifiche allo script (codice) in un branch di feature.
2. Fai commit di queste modifiche nel tuo repository locale.
3. Esegui il push del branch sul repository remoto, ad esempio GitHub.
4. Apri una pull request per proporre le modifiche al branch principale.
5. Richiedi una review delle modifiche proposte.
6. Fondi (merge) o chiudi la pull request a seconda dell’esito.

Questo workflow dà a ogni sviluppatore la possibilità di rivedere il codice e individuare potenziali problemi prima di inviarlo in produzione.

I ruoli chiave nel processo di pull request includono:

• Contributor: lo sviluppatore che apporta le modifiche e apre la pull request.
• Reviewer: lo sviluppatore che rivede le modifiche proposte per suggerire miglioramenti e garantire la qualità del codice.
• Maintainer: il project manager che possiede il progetto e ha i permessi per approvare o rifiutare le pull request. 

Ti consiglio di seguire il nostro corso Intermediate Git per imparare a creare branch in Git e collaborare da remoto con i membri del team.

Creare una pull request (con un esempio)

Poniamo che tu noti un errore nella riga di introduzione del file README del tuo progetto. Vuoi correggere il problema senza toccare il branch principale. Segui i passaggi qui sotto:

Passaggio 1: crea un nuovo branch

Vai nella cartella del tuo progetto e apri il terminale per eseguire il comando seguente. Questa riga crea un altro branch.

git checkout -b fix-readme-typoOfferto da

Passaggio 2: apporta la modifica

Per correggere il file, apri README.md nel tuo editor di codice, correggi il refuso e poi salva il file.

Passaggio 3: esegui il commit delle modifiche

Metti in stage ed esegui il commit delle modifiche usando il comando seguente:

git add README.md
git commit -m "Fix typo in README"Offerto da

Passaggio 4: esegui il push del branch su GitHub

Carica il branch sul repository.

git push origin fix-readme-typoOfferto da

Passaggio 5: apri GitHub e crea una pull request

Ora apri il tuo account GitHub e fai quanto segue:

• Vai al tuo repository su GitHub.

• Seleziona il prompt Compare & pull request per il branch che hai pushato.

• Aggiungi un titolo come Fix typo in README e, se vuoi, una breve descrizione.

• Scegli il tuo branch di base (di solito main) e confrontalo con il tuo branch di feature.

Passaggio 6: richiedi la review e invia

Se il tuo progetto coinvolge altri sviluppatori, puoi richiedere dei reviewer o aggiungere etichette se il progetto le usa. Poi fai clic su Create pull request.

Dai un’occhiata al nostro progetto su Performing a Code Review per capire come rivedere e apportare modifiche prima di inviare il codice in produzione.

Best practice per le pull request

Di seguito trovi le best practice per garantire uno sviluppo di qualità quando crei pull request:

• Mantieni le pull request mirate e semplici: inizia sempre con una pull request per ogni funzionalità che vuoi proporre. Questo aiuta il reviewer a tracciare e testare le modifiche e riduce al minimo il rischio di introdurre bug.
• Scrivi messaggi di commit e descrizioni chiari: fornisci messaggi di commit descrittivi per spiegare le modifiche. Questo contesto aiuta i reviewer a capire le tue intenzioni senza dover scavare nel codice.  
• Sfrutta le pull request in bozza per feedback anticipati: se il tuo lavoro non è completo ma vuoi un feedback, crea una pull request in bozza. Indica che il tuo codice è in lavorazione e apre la discussione senza l’obbligo di fare subito il merge.
• Testa a fondo e condividi il contesto: controlla sempre due volte le tue modifiche per assicurarti che tutto funzioni come ti aspetti.

Pull request nei diversi workflow Git

Ecco una rapida panoramica di come diversi contesti di team usano le pull request.

• Feature branching: comune nei team piccoli e nei repository privati. Questo workflow prevede la creazione di un nuovo branch per ogni funzionalità. 

• Forking workflow: usato nei progetti open source. Il forking workflow richiede ai contributor di fare il fork (copiare) del repository principale nel proprio account. Le modifiche vengono fatte nel fork e poi si apre una pull request verso l’originale.

• GitFlow: workflow strutturato che usa branch di lungo periodo come main, develop, release e hotfix. È usato da team più grandi con cicli di rilascio più articolati.

Galateo delle pull request

Si può anche essere scortesi, quindi le pull request hanno un loro galateo:

• Sii rispettoso e specifico: concentrati sul codice, non sulla persona.
• Mantieni le pull request focalizzate: evita di mescolare modifiche non correlate nella stessa pull request. Ignorare questo punto rende solo più complicate review e feedback.
• Rispondi con attenzione ai feedback: riconosci il codice ben scritto e i suggerimenti di miglioramento.
• Non lasciare le pull request in sospeso troppo a lungo: cerca sempre di rivedere e risolvere le pull request il più velocemente possibile per evitare di ritardare gli aggiornamenti.
• Fai domande: se qualcosa non è chiaro, chiedi chiarimenti invece di presumere le intenzioni, per evitare fraintendimenti.
• Suggerisci miglioramenti: quando opportuno, offri consigli attuabili o approcci alternativi invece di limitarti a segnalare i problemi.

Workflow avanzati e best practice per le pull request

Se sei uno sviluppatore esperto e vuoi rendere la collaborazione più fluida, migliorare la qualità del codice e scalare il processo di pull request, ecco alcuni consigli pratici per affinare il tuo workflow.

Workflow più intelligenti

Vari workflow Git gestiscono le pull request in modo diverso. Come detto prima, il feature branching è ideale per i team piccoli per via della sua semplicità, ma può diventare difficile da mantenere con la crescita del team.

Il forking è consigliato per i progetti open source ma può introdurre un overhead nel sincronizzare e rivedere i contributi esterni. Allo stesso modo, GitFlow è consigliato in contesti di sviluppo frenetici, sebbene la sua complessità possa rallentare il processo. 

Automazione e integrazione

Le pull request moderne hanno i controlli CI/CD, che automatizzano le barriere di qualità integrando strumenti di integrazione continua che eseguono test e linters e distribuiscono anteprime ad ogni PR. Questo assicura che venga fatto il merge solo del codice che supera gli standard definiti.

Piattaforme come GitHub Actions e GitLab Pipelines consentono inoltre l’automazione. Questi processi includono l’esecuzione di unit test, la creazione e la pubblicazione di ambienti di anteprima, riducendo il lavoro manuale e intercettando i problemi in anticipo.

Ottimizzare le review

Mantieni sempre le pull request piccole e focalizzate, così possono essere revisionate in modo rapido e approfondito. Usare template con campi chiari come “Cosa è cambiato” e “Come testare” aiuta i contributor a fornire informazioni concise e pertinenti, rendendo le review più efficienti.

Tieni anche presente che fare domande invece di imporre richieste favorisce un dialogo costruttivo e l’apprendimento. Se definisci tempi di risposta per le review, manterrai il processo prevedibile ed eviterai ritardi.

Metriche e strumenti moderni

Consiglio inoltre di tracciare la dimensione delle PR, il tempo di review e il tasso di merge per individuare i colli di bottiglia e migliorare l’efficienza del workflow. Per semplificare le review e il merge, prova a usare pull request “stacked”, che suddividono grandi funzionalità in PR più piccole e collegate tra loro.

Inoltre, puoi integrare strumenti di IA come GitHub Copilot o CodeWhisperer quando usi le pull request. Questi strumenti ti aiutano a evidenziare potenziali problemi in anticipo e suggeriscono come correggerli.

Pull request vs. merge request

Su GitHub e GitLab, Pull Request (PR) e Merge Request (MR) sono usati in modo intercambiabile. Anche se servono allo stesso scopo, ogni piattaforma le gestisce in modo diverso.

La tabella sotto confronta PR e MR per evidenziare queste differenze.

Conclusione

Le pull request sono qualcosa che devi conoscere per qualsiasi progetto serio. Come hai visto (e spero ora apprezzi), permettono ai team di rivedere, discutere e migliorare il codice in modo collaborativo.

Continua a migliorare le tue competenze da sviluppatore. Dai un’occhiata ai nostri percorsi di skill Git Fundamentals e GitHub Foundations per diventare esperto di tutto ciò che riguarda Git.