Flusso di lavoro Feature Branch Git
L'idea principale alla base del flusso di lavoro Feature Branch è che l'intero sviluppo delle funzionalità avviene in un branch dedicato anziché in quello principale. Questo incapsulamento rende facile per più sviluppatori lavorare su una particolare funzionalità senza toccare la base di codice principale. Significa anche che il ramo principale non conterrà mai codice errato, il che è un enorme vantaggio per gli ambienti di continuous integration.
Lo sviluppo di funzionalità incapsulate consente anche di sfruttare le pull request, che sono un modo per avviare discussioni su un branch. Queste richieste permettono agli altri di accedere a una funzionalità prima che venga integrata nel progetto ufficiale. Oppure, se rimani bloccato in una funzionalità, puoi aprire una pull request per chiedere suggerimenti ai tuoi colleghi. Il punto è che le pull request permettono al tuo team di commentare il lavoro degli altri con straordinaria facilità.
Il flusso di lavoro Feature Branch di Git è un flusso di lavoro componibile che può essere sfruttato da altri flussi di lavoro Git generali. Abbiamo discusso di altri flussi di lavoro Git nella pagina di panoramica dei flussi di lavoro Git. Il flusso di lavoro Feature Branch di Git è incentrato sui modelli ramificati, il che significa che è un framework guida per la gestione e la creazione di branch. Gli altri flussi di lavoro sono più incentrati sui repository. Il flusso di lavoro Feature Branch di Git può essere incorporato in altri flussi di lavoro. I flussi di lavoro Gitflow e Git Forking Workflows utilizzano tradizionalmente un flusso di lavoro Feature Branch di Git per quanto riguarda i loro modelli di ramificazione.
Come funziona
Il flusso di lavoro Feature Branch presuppone un repository centrale e main rappresenta la cronologia ufficiale del progetto. Invece di eseguire il commit direttamente nel branch main locale, gli sviluppatori creano un nuovo branch ogni volta che iniziano a lavorare su una nuova funzionalità. I branch delle funzionalità devono avere nomi descrittivi, come voci-menu-animate o problema-#1061. L'idea è di dare uno scopo chiaro e altamente mirato a ciascun branch. Git non fa alcuna distinzione tecnica tra il ramo main e i rami delle funzionalità, quindi gli sviluppatori possono modificare, organizzare e apportare modifiche a un branch di funzionalità.
Inoltre, le branch delle funzionalità possono (e devono) essere trasferite nel repository centrale. In questo modo è possibile condividere una funzionalità con altri sviluppatori senza toccare alcun codice ufficiale. Poiché main è l'unico branch «speciale», la memorizzazione di diversi branch di funzionalità nel repository centrale non pone problemi. Naturalmente, si tratta anche di un modo conveniente per eseguire il backup dei commit locali di tutti. Quella che segue è una panoramica del ciclo di vita di un branch di funzionalità.
Inizia con il branch principale
Tutti i branch di funzionalità sono creati in base allo stato del codice più recente di un progetto. Questa guida presuppone che sia mantenuto e aggiornato nel branch main.
materiale correlato
Registro Git avanzato
Scopri la soluzione
Impara a utilizzare Git con Bitbucket Cloud
git checkout main
git fetch origin
git reset --hard origin/mainCrea il repository
Questo passa il repository al branch main, estrae gli ultimi commit e reimposta la copia locale di main del repository in modo che corrisponda alla versione più recente.
Crea nuovo branch
Usa un branch separato per ogni funzione o problema su cui lavori. Dopo aver creato un branch, esegui un checkout a livello locale, in modo che tutte le modifiche apportate avvengano su quel branch.
git checkout -b new-featureQuesto comando verifica un branch chiamato new-feature basato su main e il flag -b dice a Git di creare il branch se non esiste già.
Aggiorna, aggiungi, conferma ed esegui il push delle modifiche
In questo branch, modifica, prepara ed esegui il commit delle modifiche come di consueto, sviluppando la funzionalità con tutti i commit necessari. Lavora sulla funzione ed esegui il commit come faresti ogni volta che usi Git. Quando sei pronto, esegui il push dei tuoi commit, aggiornando il branch delle funzionalità su Bitbucket.
git status
git add <some-file>
git commitSpostare il branch della funzionalità su remoto
È una buona idea eseguire il push del branch delle funzionalità nel repository centrale. Questo funge da comodo backup: quando si collabora con altri sviluppatori, darebbe loro accesso alla visualizzazione dei commit nel nuovo branch.
git push -u origin new-featureQuesto comando invia una nuova funzionalità al repository centrale (origine) e il flag -u la aggiunge come branch di tracciamento remoto. Dopo aver impostato il branch di tracciamento, git push può essere richiamato senza parametri per eseguire automaticamente il push del branch con la nuova funzionalità al repository centrale. Per ottenere feedback sul nuovo branch di funzionalità, crea una pull request in una soluzione di gestione dei repository come Bitbucket Cloud o Bitbucket Data Center. Da lì, puoi aggiungere revisori e assicurarti che tutto sia a posto prima dell'unione.
Risolvi il feedback
Ora i compagni di squadra commentano e approvano i commit inviati. Risolvi i loro commenti a livello locale, conferma ed esegui il push delle modifiche suggerite a Bitbucket. I tuoi aggiornamenti vengono visualizzati nella pull request.
Unire la pull request
Prima dell'unione, potrebbe essere necessario risolvere i relativi conflitti se altri hanno apportato modifiche al repository. Quando la tua pull request è approvata e non contiene conflitti, puoi aggiungere il tuo codice al branch main. Esegui l'unione dalla pull request in Bitbucket.
Pull request
Oltre a isolare lo sviluppo delle funzionalità, i branch consentono di discutere le modifiche tramite pull request. Una volta che qualcuno completa una funzionalità, non la unisce immediatamente a quella main. Invia invece il branch di funzionalità al server centrale e invia una pull request chiedendo di unire le sue aggiunte a quelle main. Ciò offre agli altri sviluppatori l'opportunità di esaminare le modifiche prima che diventino parte della base di codice principale.
La revisione del codice è uno dei principali vantaggi delle pull request, ma queste ultime in realtà sono pensante per essere un modo generico di parlare del codice. Puoi pensare alle pull request come a una discussione dedicata a un branch specifico. Ciò significa che possono essere utilizzate anche molto prima nel processo di sviluppo. Ad esempio, se uno sviluppatore ha bisogno di aiuto con una particolare funzionalità, tutto ciò che deve fare è presentare una pull request. Le parti interessate riceveranno una notifica automatica e potranno vedere la domanda accanto ai documenti pertinenti.
Una volta accettata una pull request, l'atto effettivo di pubblicazione di una funzionalità è più o meno lo stesso del flusso di lavoro centralizzato. Innanzitutto, devi assicurarti che la tua rete locale principale sia sincronizzata con la rete principale upstream. Quindi, unisci il ramo delle funzionalità in principale e reinserisci il file principale aggiornato nel repository centrale.
Le pull request possono essere facilitate da soluzioni di gestione del codice sorgente come Bitbucket Cloud.
Esempio
Di seguito è riportato un esempio del tipo di scenario in cui viene utilizzato un flusso di lavoro di ramificazione delle funzionalità. Lo scenario è quello di un team che esegue una revisione del codice su una nuova pull request di funzionalità. Questo è un esempio dei molti scopi per cui può essere usato questo modello.
Mary inizia una nuova funzionalità
Prima di iniziare a sviluppare una funzionalità, Mary ha bisogno di un branch isolato su cui lavorare. Può richiedere un nuovo branch con il seguente comando:
git checkout -b marys-feature mainQuesto comando verifica un branch chiamato marys-feature basato su main e il flag -b dice a Git di creare il branch se non esiste già. In questo branch, Mary modifica, prepara ed esegue il commit delle modifiche come di consueto, sviluppando la funzionalità con tutti i commit necessari.
git status
git add <some-file>
git commitMary va a pranzo
.svg?cdnVersion=2441)
Mary aggiunge alcuni commit alla sua funzionalità nel corso della mattinata. Prima che parta per pranzo, è una buona idea eseguire il push del branch di funzionalità nel repository centrale. Questo funge da comodo backup, ma se Mary collaborasse con altri sviluppatori, questo consentirebbe loro di accedere anche ai suoi commit iniziali.
git push -u origin marys-featureQuesto comando invia marys-feature al repository centrale (origine) e il flag -u la aggiunge come branch di tracciamento remoto. Dopo aver impostato il branch di tracciamento, Mary può chiamare git push senza parametri per eseguire il push della sua funzione.
Mary termina la funzionalità
Quando Mary torna dal pranzo, completa la propria funzionalità Prima di unirla a main, deve presentare una pull request per far sapere al resto del team che ha finito. Ma prima dovrebbe assicurarsi che l'archivio centrale contenga i suoi commit più recenti:
git pushQuindi, invia la pull request nella sua GUI Git chiedendo di unire marys-feature a quella main e i membri del team riceveranno una notifica automaticamente. Il bello delle pull request è che mostrano i commenti accanto ai relativi commit, quindi è facile porre domande su specifici changeset.
Bill riceve la pull request
.svg?cdnVersion=2441)
Bill riceve la pull request e dà un'occhiata a marys-feature . Decide di voler apportare alcune modifiche prima di integrarlo nel progetto ufficiale, e lui e Mary fanno discutono tramite la pull request.
Mary apporta le modifiche
.svg?cdnVersion=2441)
Per apportare le modifiche, Mary utilizza esattamente la stessa procedura utilizzata per creare la prima iterazione della sua funzionalità. Modifica, organizza, esegue il commit e invia gli aggiornamenti al repository centrale. Tutta la sua attività viene visualizzata nella pull request e Bill può ancora fare commenti in questa fase.
Se volesse, Bill potrebbe inserire marys-feature nel suo repository locale e lavorarci da solo. Qualsiasi commit che aggiungerà verrà visualizzato anche nella pull request.
Mary pubblica la funzionalità
Una volta che Bill è pronto ad accettare la pull request, qualcuno deve unire la funzionalità nel progetto stabile (operazione effettuabile da Bill o Mary):
git checkout main
git pull
git pull origin marys-feature
git pushquesto processo si traduce spesso in un processo di unione. Ad alcuni sviluppatori piace perché è come un'unione simbolica della funzionalità con il resto della base del codice. Tuttavia, se preferisci una cronologia lineare, è possibile ribasare la funzionalità alla fine del codice main prima di eseguire l'unione, per una conseguente unione rapida.
Alcune GUI automatizzeranno il processo di accettazione delle pull request eseguendo tutti questi comandi semplicemente facendo clic sul pulsante «Accetta». Se la tua GUI non lo fa, dovrebbe almeno essere in grado di chiudere automaticamente la pull request quando il branch di funzionalità viene unito a quello main.
Nel frattempo, John sta facendo esattamente la stessa cosa.
Mentre Mary e Bill stanno lavorando a marys-eature e ne stanno discutendo nella sua pull request, John sta facendo esattamente la stessa cosa con il suo branch di funzionalità. Isolando le funzionalità in branch separati, tutti possono lavorare in modo indipendente, ma è comunque sempre molto facile condividere le modifiche con altri sviluppatori quando necessario.
Riepilogo
In questo documento, abbiamo discusso del flusso di lavoro Git Feature Branch. Questo flusso di lavoro aiuta a organizzare e tenere traccia dei branch incentrati sui set di funzionalità del dominio aziendale. Altri flussi di lavoro Git come Git Forking Workflow e Gitflow sono focalizzati sui repository e possono sfruttare il flusso di lavoro Git Feature Branch per gestire i propri modelli di branch. Questo documento dimostra un esempio di codice generale e un esempio fittizio per l'implementazione del flusso di lavoro Git Feature Branch. Alcune associazioni chiave da creare con il flusso di lavoro Feature Branch:
- sono focalizzate su schemi di branch
- possono essere sfruttate da altri flussi di lavoro orientati ai repository
- promuovono la collaborazione con i membri del team attraverso pull request e analisi delle unioni
L'utilizzo di git rebase durante le fasi di revisione e unione di un ramo di funzionalità creerà una cronologia Git coerente delle unioni di funzionalità. Un modello di branch delle funzionalità è un ottimo strumento per promuovere la collaborazione all'interno di un ambiente di team.
Approfondisci con un clic i flussi di lavoro Git leggendo il nostro tutorial completo sul flusso di lavoro Gitflow.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.
Blog di Bitbucket
Percorso di apprendimento DevOps
