Esplorare il flusso di lavoro del ramo funzionalità
L'idea alla base del flusso di lavoro dei rami di funzionalità è che lo sviluppo di tutte le funzionalità deve avvenire in un ramo dedicato anziché nel ramo principale.
Questo incapsulamento consente a più sviluppatori di lavorare su una particolare funzionalità senza compromettere la codebase principale. Questo significa anche che il ramo principale non conterrà mai codice non funzionante,il che rappresenta un enorme vantaggio per gli ambienti di integrazione continua.
L'incapsulamento dello sviluppo di funzionalità consente anche di usare le richieste pull, che rappresentano un modo per avviare discussioni relative a un ramo. Gli sviluppatori possono così scartare una funzionalità prima che venga integrata nel progetto ufficiale. Se inoltre si rimane bloccati durante lo sviluppo di una funzionalità, è possibile aprire una richiesta pull per chiedere suggerimenti ai colleghi.
Le richieste pull rappresentano un modo estremamente semplice per il team di commentare il lavoro dei colleghi. Per i rami di funzionalità è inoltre possibile (e necessario) eseguire il push nel repository centrale. Ciò consente di condividere una funzionalità con altri sviluppatori senza intervenire sul codice ufficiale.
Poiché il ramo principale è l'unico ramo "speciale", l'archiviazione di diversi rami di funzionalità nel repository centrale non comporta problemi. È anche un modo pratico per eseguire il backup dei commit locali di ognuno.
Flusso di lavoro del ramo di versione
Oltre al flusso di lavoro del ramo di funzionalità, un'altra strategia comunemente usata nei flussi di lavoro di rami Git è la strategia del ramo di versione. Questa strategia implica la creazione di rami dedicati specificamente per la preparazione delle versioni. Il ramo di versione viene in genere creato da un ramo di funzionalità stabile, assicurandosi che contenga solo codice testato e convalidato accuratamente. Dopo la creazione, il ramo di versione viene sottoposto a test aggiuntivi, correzioni di bug e lavori di stabilizzazione, al fine di preparare la codebase per la distribuzione. Il ramo di versione consente l'isolamento delle attività correlate al rilascio dallo sviluppo continuo delle funzionalità, fornendo un ambiente controllato per finalizzare e completare la versione futura. Dopo aver apportato tutte le modifiche e le verifiche necessarie nel ramo di versione, viene quindi unito nel ramo principale o distribuito direttamente nell'ambiente di produzione, a seconda del processo di versione del team. La strategia del ramo di versione aiuta i team a gestire le complessità del coordinamento delle attività di versione, mantenendo al tempo stesso un ramo principale stabile per lo sviluppo in corso.
Flusso di lavoro di sviluppo basato su trunk
Il flusso di lavoro di sviluppo basato su trunk presuppone un repository centrale, mentre il ramo principale rappresenta la cronologia ufficiale del progetto. Invece di eseguire il commit direttamente nel ramo principale locale, gli sviluppatori creano un nuovo ramo ogni volta che iniziano a lavorare a una nuova funzionalità. I rami di funzionalità devono avere nomi descrittivi, ad esempio new-banner-images o bug-91. L'idea di base è assegnare uno scopo chiaro e altamente mirato a ogni ramo.
Git non fa alcuna distinzione tecnica tra il ramo principale e i rami di funzionalità, pertanto gli sviluppatori possono modificare, preparare per il commit ed eseguire il commit delle modifiche per un ramo di funzionalità.
Creare un ramo
Quando si lavora a un progetto, emergono spesso molte funzionalità o idee diverse in corso in ogni momento, alcune delle quali sono pronte per la realizzazione, mentre altre no. La creazione di rami aiuta a gestire questo flusso di lavoro. Quando si crea un ramo nel progetto, si crea un ambiente in cui è possibile provare nuove idee.
Oltre a creare rami per nuove funzionalità o correzioni, i team che seguono un flusso di lavoro del ramo di versione creano rami dedicati specificamente per la preparazione delle versioni. Questi rami di versione sono in genere derivati da rami di funzionalità stabili, per assicurarsi che contengano codice accuratamente testato e convalidato. Dopo la creazione, il ramo di versione viene sottoposto a test aggiuntivi, correzioni di bug e lavori di stabilizzazione, al fine di preparare la codebase per la distribuzione.
Aggiungere commit
Una volta creato il ramo, è possibile iniziare ad apportare modifiche. Ogni volta che si aggiunge, si modifica o si elimina un file, si esegue un commit e lo si aggiunge al ramo.
L'aggiunta di commit consente di tenere traccia dello stato di avanzamento quando si lavora a un ramo di funzionalità.
I commit creano anche una cronologia trasparente del lavoro che altri utenti possono seguire per comprendere cosa è stato fatto e perché.
A ogni commit è associato un messaggio che spiega perché è stata apportata una modifica specifica.
Ogni commit viene inoltre considerato un'unità separata di modifica. Consente di eseguire il rollback delle modifiche se viene trovato un bug o si decide di prendere una direzione diversa.
I messaggi di commit sono essenziali, soprattutto perché Git tiene traccia delle modifiche e le visualizza come commit dopo il push nel server.
Scrivendo messaggi di commit chiari, si aiutano gli altri utenti a seguire il processo e fornire feedback.
Open a pull request
Le richieste pull consentono di avviare una discussione sui commit. Poiché sono strettamente integrate con il repository Git sottostante, chiunque può vedere esattamente le modifiche di cui verrà eseguito il merge accettando la richiesta.
È possibile aprire una richiesta pull in qualsiasi momento durante il processo di sviluppo quando:
- Si ha poco codice, o per nulla, ma si vogliono condividere screenshot o idee generali.
- Si è bloccati e si ha bisogno di aiuto o di un consiglio.
- Si è pronti per far rivedere il lavoro a un'altra persona.
Usando il sistema @mention nel messaggio di richiesta pull, è possibile richiedere un feedback a persone o team specifici, indipendentemente dal fatto che si trovino nell'ufficio vicino o a 10 fusi orari di distanza.
Le richieste pull aiutano a contribuire ai progetti e alla gestione delle modifiche ai repository condivisi.
Se si usa un modello di tipo fork e pull, le richieste pull forniscono un modo per segnalare ai gestori del progetto le modifiche che si desidera che vengano prese in considerazione.
Se si usa un modello di repository condiviso, le richieste pull consentono di avviare la revisione del codice e la conversazione sulle modifiche proposte prima del merge nel ramo principale.
Discutere e rivedere il codice
Dopo l'apertura di una richiesta pull, la persona o il team che esamina le modifiche può avere domande o commenti.
Lo stile di scrittura del codice potrebbe ad esempio non corrispondere alle linee guida del progetto, nella modifica potrebbero mancare gli unit test o magari tutto è eccellente e le proprietà sono in ordine.
Le richieste pull sono pensate per incoraggiare e acquisire questo tipo di conversazione.
È anche possibile continuare a eseguire il push nel ramo, prendendo in considerazione la discussione e il feedback sui commit.
Si supponga che qualcuno nei commenti indichi che c'è stata una dimenticanza o che è presente un bug nel codice, è possibile correggere il problema nel ramo ed eseguire il push della modifica.
Git mostra i nuovi commit e l'eventuale feedback ricevuto nella visualizzazione unificata relativa alle richieste pull.
I commenti delle richieste pull sono scritti in Markdown, quindi è possibile incorporare immagini ed emoji, usare blocchi di testo preformattati e usare altri tipi di formattazione leggera.
Distribuzione
Con Git è possibile eseguire la distribuzione da un ramo per il test finale in un ambiente prima del merge nel ramo principale.
Dopo che la richiesta pull è stata esaminata e il ramo supera i test, è possibile distribuire le modifiche per verificarle. Se il ramo causa problemi, è possibile eseguirne il rollback distribuendo il ramo principale esistente.
Unire
Una volta verificate le modifiche, è possibile eseguire il merge del codice nel ramo principale.
Dopo il merge, le richieste pull conservano un record delle modifiche cronologiche apportate al codice. Poiché è possibile eseguire ricerche al loro interno, chiunque può tornare indietro nel tempo per capire perché e come è stata presa una decisione.
Incorporando parole chiave specifiche nel testo della richiesta pull, è possibile associare i problemi al codice. Quando viene eseguito il merge della richiesta pull, è possibile chiudere anche i problemi correlati.
Questo flusso di lavoro consente di organizzare e monitorare i rami incentrati sui set di funzionalità del dominio aziendale.
Altri flussi di lavoro Git, come la creazione di copie tramite fork e GitFlow, sono incentrati sul repository e possono usare il flusso di lavoro dei rami di funzionalità Git per gestire i modelli di diramazione.