Workflow delle pull request su GitHub

Una Pull Request (PR) è una proposta di merge di un branch in un altro. Su GitHub crea una discussione in cui i membri del team esaminano il codice, lasciano commenti, richiedono modifiche e infine approvano il merge.

Dopo aver eseguito il push di un branch per una funzionalità su GitHub, compare un banner giallo che offre la possibilità di confrontare i branch e creare una PR. Faccia clic su di esso oppure vada a Pull Requests → New pull request e selezioni i branch.

Una buona descrizione della PR spiega che cosa è cambiato e perché. Includa uno screenshot per le modifiche all'interfaccia utente. Colleghi l'issue correlata. Descriva come ha eseguito i test. Il lettore non dovrebbe dover leggere il codice per comprendere l'intento.

Assegni membri specifici del team come revisori. Riceveranno una notifica e potranno approvare, richiedere modifiche o commentare. La maggior parte dei team richiede almeno un'approvazione prima del merge.

I commenti compaiono in linea sulle righe modificate. I revisori possono chiedere chiarimenti, suggerire un approccio diverso o approvare. Risponda a ogni commento, con una modifica al codice oppure spiegando perché non apportarla.

Quando un revisore richiede modifiche, esegua nuovi commit sullo stesso branch. La PR si aggiorna automaticamente. Risolva ogni conversazione facendo clic su 'Resolve conversation' dopo aver apportato la modifica richiesta.

Apra una PR come Draft per segnalare che il lavoro è in corso. Le PR in bozza consentono comunque la revisione e la discussione, ma non possono essere unite per errore. La converta in Ready quando è completa.

Quando main avanza durante la revisione, esegua il rebase del branch sull'ultimo main per evitare conflitti e assicurarsi che le modifiche funzionino con il nuovo codice.

GitHub offre tre strategie di merge: Merge commit (conserva tutti i commit), Squash and merge (un commit per PR, con una cronologia di main pulita), Rebase and merge (lineare, senza commit di merge). In genere i team scelgono una strategia per mantenere la coerenza.

Protegga main richiedendo la revisione delle PR, imponendo il superamento dei controlli di stato (CI) e vietando i push diretti. La configurazione si trova in GitHub → Settings → Branches.

Mantenga le PR piccole e mirate. Una PR per ogni funzionalità o correzione. Le PR grandi sono difficili da esaminare. Risponda ai commenti della revisione entro un giorno. Ringrazi i revisori. Sia gentile: la code review è un'opportunità di apprendimento, non un audit.

Che cosa dovrebbe includere una buona descrizione della PR?

Eseguire il push del branch della funzionalità → aprire una PR con una descrizione chiara → richiedere revisori → gestire il feedback con nuovi commit → mantenere il branch aggiornato con il rebase → ottenere l'approvazione → eseguire il merge. Mantenga le PR piccole, mirate e ben descritte. Le regole di protezione dei branch garantiscono la qualità di main.