Come effettuare una pull request
Le pull request sono una funzione che semplifica la collaborazione tra sviluppatori tramite Bitbucket. Utilizzando la loro intuitiva interfaccia web, puoi discutere sulle modifiche proposte prima di integrarle nel progetto ufficiale.
Nella loro forma più semplice, le pull request sono un meccanismo che consente a uno sviluppatore di notificare ai membri del team che hanno completato una funzionalità. Una volta che il loro branch di funzionalità è pronto, lo sviluppatore invia una pull request tramite il proprio account Bitbucket. Questo fa sapere a tutte le persone coinvolte che devono rivedere il codice ed eseguirne il merge nel branch main.
Ma la pull request è più di una semplice notifica: è un forum dedicato per discutere della funzionalità proposta. In caso di problemi con le modifiche, i membri del team possono pubblicare feedback nella pull request e persino modificare la funzione eseguendo il push dei commit di follow-up. Tutta questa attività viene tracciata direttamente all'interno della pull request.
Rispetto ad altri modelli di collaborazione, questa soluzione formale per la condivisione degli impegni rende il flusso di lavoro molto più snello. SVN e Git possono entrambi inviare automaticamente e-mail di notifica con un semplice script; tuttavia, quando si tratta di discutere delle modifiche, gli sviluppatori in genere devono fare affidamento sui thread di posta elettronica. Ciò può presentare problemi, soprattutto quando sono coinvolti commit di follow-up. Le pull request inseriscono tutte queste funzionalità in un'interfaccia web intuitiva accanto ai tuoi repository Bitbucket.
Anatomia di una pull request
Quando presenti una pull request, tutto ciò che stai facendo è richiedere che un altro sviluppatore (ad esempio, il responsabile del progetto) estragga un branch dal tuo repository al suo repository. Ciò significa che devi fornire 4 informazioni per presentare una pull request: il repository di origine, il branch di origine, il repository di destinazione e il branch di destinazione.
Molti di questi valori saranno impostati su un valore predefinito ideale da Bitbucket. Tuttavia, a seconda del flusso di lavoro collaborativo, il tuo team potrebbe dover specificare valori diversi. Il diagramma sopra mostra una pull request che chiede di unire un branch di funzionalità nel branch main ufficiale, ma ci sono molti altri modi per utilizzare le pull request.
Come funziona
Le pull request possono essere utilizzate insieme al flusso di lavoro Feature Branch, al flusso di lavoro Gitflow o al flusso di lavoro Forking. Tuttavia, una pull request richiede due branch distinti o due repository distinti, quindi non funzionerà con il flusso di lavoro centralizzato. L'utilizzo delle pull request con ciascuno di questi flussi di lavoro è leggermente diverso, ma il processo generale è il seguente:
Uno sviluppatore crea la funzionalità in un branch dedicato nel proprio repository locale.
Lo sviluppatore trasferisce il branch in un repository Bitbucket pubblico.
Lo sviluppatore invia una pull request tramite Bitbucket.
Il resto del team esamina il codice, ne discute e lo modifica.
Il responsabile del progetto esegue il merge della funzionalità nel repository ufficiale e chiude la pull request.
Il resto di questa sezione descrive come le pull request possono essere sfruttate su diversi flussi di lavoro di collaborazione.
Flusso di lavoro Feature Branch con pull request
Il flusso di lavoro Feature Branch utilizza un repository Bitbucket condiviso per la gestione della collaborazione e gli sviluppatori creano funzionalità in branch isolati. Tuttavia, invece di eseguirne immediatamente il merge in main, gli sviluppatori dovrebbero aprire una pull request per avviare una discussione sulla funzionalità prima che venga integrata nella base di codice principale.
C'è un solo repository pubblico nel flusso di lavoro Feature Branch, quindi il repository di destinazione della pull request e il repository di origine saranno sempre gli stessi. In genere, lo sviluppatore specificherà il proprio branch di funzionalità come branch di origine e il branch main come branch di destinazione.
Dopo aver ricevuto la pull request, il responsabile del progetto deve decidere cosa fare. Se la funzione è pronta per l'uso, può semplicemente eseguirne il merge in main e chiudere la pull request. Tuttavia, se ci sono problemi con le modifiche proposte, può pubblicare feedback nella pull request. I commit di follow-up verranno visualizzati accanto ai commenti pertinenti.
È anche possibile presentare una pull request per una funzionalità incompleta. Ad esempio, se uno sviluppatore ha problemi a implementare un requisito particolare, può presentare una pull request contenente i propri lavori in corso. Gli altri sviluppatori possono quindi fornire suggerimenti all'interno della pull request o persino risolvere il problema da soli con commit aggiuntivi.
Flusso di lavoro Gitflow con pull request
Il flusso di lavoro Gitflow è simile al flusso di lavoro Feature Branch, ma definisce un modello di branching rigoroso progettato in base alla versione del progetto. L'aggiunta di pull request al flusso di lavoro Gitflow offre agli sviluppatori un posto comodo per parlare di un branch di funzionalità o di manutenzione mentre ci stanno lavorando.
I meccanismi delle pull request nel flusso di lavoro Gitflow sono esattamente gli stessi della sezione precedente: uno sviluppatore invia semplicemente una pull request quando una funzionalità, una versione o un hotfix devono essere esaminati e il resto del team riceverà una notifica tramite Bitbucket.
Le funzionalità sono generalmente unite nel branch develop, mentre i branch di funzionalità e hotfix vengono sottoposti a merge sia in develop che in main. Le pull request possono essere utilizzate per gestire formalmente tutti questi merge.
Flusso di lavoro Forking con pull request
Nel Flusso di lavoro Forking, uno sviluppatore trasferisce una funzionalità completa nel proprio repository pubblico anziché in uno condiviso. Dopodiché, presenta una pull request per far sapere al responsabile del progetto che è pronto per la revisione.
L'aspetto delle notifiche delle pull request è particolarmente utile in questo flusso di lavoro perché il responsabile del progetto non ha modo di sapere quando un altro sviluppatore ha aggiunto dei commit al proprio repository Bitbucket.
Poiché ogni sviluppatore ha il proprio repository pubblico, il repository di origine della pull request sarà diverso dal suo repository di destinazione. Il repository di origine è il repository pubblico dello sviluppatore e il branch di origine è quello che contiene le modifiche proposte. Se lo sviluppatore sta cercando di eseguire il merge della funzionalità nella base di codice principale, il repository di destinazione è il progetto ufficiale e il branch di destinazione è main.
Le pull request possono essere utilizzate anche per collaborare con altri sviluppatori al di fuori del progetto ufficiale. Ad esempio, se uno sviluppatore stava lavorando a una funzionalità con un compagno di squadra, potrebbe presentare una pull request utilizzando il repository Bitbucket del compagno di squadra per la destinazione anziché il progetto ufficiale. Quindi, userebbe lo stesso branch di funzionalità per i branch di origine e di destinazione.
I due sviluppatori potrebbero discutere e sviluppare la funzionalità all'interno della pull request. Al termine, uno di loro presenterà un'altra pull request chiedendo di unire la funzione nel branch main ufficiale. Questo tipo di flessibilità rende le pull request uno strumento di collaborazione molto potente nel flusso di lavoro Forking.
Esempio
L'esempio seguente dimostra come è possibile utilizzare le pull request nel flusso di lavoro Forking. È ugualmente applicabile agli sviluppatori che lavorano in piccoli team e a uno sviluppatore terzo che contribuisce a un progetto open source.
Nell'esempio, Mary è una sviluppatrice e John è il responsabile del progetto. Entrambi hanno i propri repository Bitbucket pubblici e quello di John contiene il progetto ufficiale.
Mary esegue un fork del progetto ufficiale
Per iniziare a lavorare al progetto, Mary deve prima eseguire un fork del repository Bitbucket di John. Può farlo accedendo a Bitbucket, accedendo al repository di John e facendo clic sul pulsante Fork.
Dopo aver compilato il nome e la descrizione del repository fork, avrà una copia del progetto sul lato server.
Mary clona il suo repository Bitbucket
Successivamente, Mary deve clonare il repository Bitbucket di cui ha appena eseguito il fork. Questo le fornirà una copia funzionante del progetto sul suo computer locale. Può farlo eseguendo il seguente comando:
git clone https://user@bitbucket.org/user/repo.gitTieni presente che git clone crea automaticamente un remoto origin che rimanda al repository fork di Mary.
Mary sviluppa una nuova funzionalità
Prima di iniziare a scrivere codice, Mary deve creare un nuovo branch per la funzione. Questo branch verrà utilizzato come branch di origine della pull request.
git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"Mary può usare tutti i commit di cui ha bisogno per creare la funzione. E, se la cronologia della funzione è più complicata di quanto vorrebbe, può usare un rebase interattivo per rimuovere o eliminare i commit non necessari. Per i progetti più grandi, ripulire la cronologia di una funzionalità rende molto più facile per il responsabile del progetto vedere cosa sta succedendo nella pull request.
Mary trasferisce la funzionalità nel suo repository Bitbucket
Una volta completata la sua funzionalità, Mary trasferisce il branch di funzionalità nel suo repository Bitbucket (non nel repository ufficiale) con un semplice git push:
git push origin some-branchQuesto rende le sue modifiche disponibili al responsabile del progetto (o a tutti i collaboratori che potrebbero aver bisogno di accedervi).
Mary crea la pull request
Dopo che Bitbucket avrà il suo branch di funzionalità, Mary può creare la pull request tramite il suo account Bitbucket accedendo al repository fork e facendo clic sul pulsante Pull request nell'angolo in alto a destra. Il modulo risultante imposta automaticamente il repository di Mary come repository di origine e le chiede di specificare il branch di origine, il repository di destinazione e il branch di destinazione.
Mary vuole eseguire il merge della sua funzionalità nella base di codice principale, quindi il branch di origine è il suo branch di funzionalità, il repository di destinazione è il repository pubblico di John e il branch di destinazione è main. Dovrà inoltre fornire un titolo e una descrizione per la pull request. Se ci sono altre persone che devono approvare il codice oltre a John, può inserirle nel campo Revisori.
Dopo aver creato la pull request, verrà inviata una notifica a John tramite il suo feed Bitbucket e (facoltativamente) via e-mail.
John esamina la pull request
John può accedere a tutte le pull request presentate dalle persone facendo clic sulla scheda Pull request nel suo repository Bitbucket. Facendo clic sulla pull request di Mary, vedrà una descrizione della pull request, la cronologia dei commit della funzionalità e un diff di tutte le modifiche che contiene.
Se ritiene che la funzionalità sia pronta per essere integrata nel progetto, tutto ciò che deve fare è premere il pulsante Merge per approvare la pull request e unire la funzionalità di Mary nel suo branch main.
Ma, per questo esempio, supponiamo che John abbia trovato un piccolo bug nel codice di Mary e abbia bisogno che lo risolva prima del merge. Può pubblicare un commento sull'intera pull request oppure può selezionare un commit specifico nella cronologia della funzionalità per commentare.
Mary aggiunge un commit di follow-up
Se Mary ha domande sul feedback, può rispondere all'interno della pull request, trattandola come un forum di discussione per la sua funzionalità.
Per correggere l'errore, Mary aggiunge un altro commit al suo branch di funzionalità e lo invia al suo repository Bitbucket, proprio come ha fatto la prima volta. Questo commit viene aggiunto automaticamente alla pull request originale e John può rivedere nuovamente le modifiche, proprio accanto al suo commento originale.
John accetta la pull request
Infine, John accetta le modifiche, unisce il branch di funzionalità a main e chiude la pull request. La funzionalità è ora integrata nel progetto e qualsiasi altro sviluppatore che ci sta lavorando può inserirla nei propri repository locali utilizzando il comando git pull standard.
Come continuare
Ora dovresti avere tutti gli strumenti necessari per iniziare a integrare le pull request nel tuo flusso di lavoro esistente. Ricorda che le pull request non sostituiscono nessuno dei flussi di lavoro di collaborazione basati su Git, ma piuttosto rappresentano una comoda aggiunta che rende la collaborazione più accessibile a tutti i membri del tuo team.
