Dotenv

Git flow: A supporto del continuous software development

Le principali tipologie di VCS

Centralized Version Control Systems (CVCSs)
Questi sistemi hanno un singolo server che contiene tutti i file versionati, dal quale diversi client prelevano i file. Il maggior difetto di questa architettura è proprio il server centralizzato, in quanto tutto il progetto e la sua history risiedono in un unico punto con il rischio di perdere tutto in caso di danneggiamento o in assenza di backup o ancora in caso non si possano salvare modifiche se è down.

Distributed Version Control Systems (DVCSs)
In questa architettura i client si creano una copia dell’intera repository, inclusa la sua history; di conseguenza ogni clone è un vero e proprio backup di tutti i dati. Di questa ultima categoria fa parte GIT.

Git è un sistema di versionamento open source che si differenzia dagli altri grazie al suo branching model (flussi di lavoro multipli) che incoraggia molteplici branch locali indipendenti l’uno dall’altro.
Il branching model favorisce lo sviluppo di applicativi da parte di team consentendo a più persone di lavorare allo stesso progetto (e agli stessi files) contemporaneamente.

GIT si basa su due principali branch:
– MASTER/MAIN: branch dedicato alla produzione
– DEVELOP: branch di sviluppo dove vengono eseguiti i test e uniti i singoli branch di sviluppo di una feature, ovvero di una funzionalità che deve essere sviluppata. Infatti, alla base di GIT troviamo un workflow basato sulle funzionalità, promuovendo la creazione un nuovo branch per ogni nuova funzione su cui sta lavorando.

Questo consente un facile switch tra branch in modo da poter passare senza problemi da uno all’altro.
Terminato lo sviluppo di una funzionalità, il branch di sviluppo viene eliminato unendolo (mergiandolo in termini tecnici) a quello ufficiale di sviluppo e test (DEVELOP).

Una volta terminati i test, quando si vuole passare in produzione si unisce il tutto in MASTER/MAIN.

Da questo concetto si sono sviluppati diversi Workflow tra i quali io prediligo Gitflow.

Gitflow

Inizialmente pubblicato da Vincent Driessen at nvie, è un workflow Git cha aiuta nel continuous software development e definisce un branching model ben definito orientato a progetti schedulati da ciclici rilasci tramite release. La sua particolarità è di non aggiungere nessun nuovo concetto alla struttura base di GIT, rimanendo negli standard definiti, fattore molto importante nello sviluppo, ma assegna ruoli specifici a differenti tipi di branch in base al loro scopo, definendo inoltre quando questi dovranno interagire tra loro e aiutando così gli sviluppatori a seguire un determinato flusso di lavoro.

I comandi introdotti, infatti, non sono altro che un raggruppamento di alcuni comandi base di GIT.

Esempio:

gitflowgitgit flow release finish 1.2.0git checkout mastergit merge –no-ff release/1.2.0git tag -a 1.2.0git checkout developgit merge –no-ff release/1.2.0git branch -d release/1.2.0

 

Branch e il loro scopo

Feature
Branch base già visto in GIT che ha origine da DEVELOP e una volta terminato viene mergiato nello stesso. Viene utilizzato in fase di sviluppo, generalmente se ne trova uno per ogni funzionalità richiesta. Consente lo sviluppo parallelo.

Release
Ha origine da DEVELOP e contiene un insieme di funzionalità in fase di preparazione per essere testate e pubblicate. Infatti, non può contenere nuovi feature branch ma solamente bug fixes, documentazione, consentendo di “fissare” lo sviluppo fatto fino a quel momento. Questo consente ad un altro team di proseguire con lo sviluppo di nuove funzionalità partendo da DEVELOP con i FEATURE.
Una volta terminato e testato, pronto quindi per essere messo in produzione, questo branch viene mergiato in MASTER/MAIN e in DEVELOP ed inoltre viene taggato con una nuova versione. Successivamente il branch viene rimosso.

Hotfix
Ha origine da MASTER/MAIN in quanto deve essere una veloce correzione di un eventuale bug presente in produzione.
Completato, deve essere mergiato in MASTER/MAIN e DEVELOP (o eventuale Release), taggando MASTER/MAIN con un aggiornamento di versione.

GOLDEN RULES

  • A develop branch is created from master/main

  • A release branch is created from develop

  • Feature branches are created from develop

  • When a feature is complete it is merged into the develop branch

  • When the release branch is done it is merged into develop and master

  • If an issue in master/main is detected a hotfix branch is created from master

  • Once the hotfix is complete it is merged to both develop and master/main

torna al blog

Potrebbe interessarti anche