Lavorare in team non è semplice: è abbastanza frequente che più sviluppatori lavorino allo stesso progetto, ma avendo a che fare con features diverse: per evitare di soccombere di fronte al merge con il codice di un collega, vediamo come usare GitFlow per gestire lo sviluppo di nuove features.

Cos’è

GitFlow è un modello di ramificazione per Git, creato da Vincent Driessen. Ha attirato molta attenzione perché è perfetto per lavori in cui si ha a che fare con altri colleghi o un team di sviluppo in continua evoluzione.

Come funziona

Ogni nuova funzionalità (o feature) dovrebbe risiedere nel proprio branch, che può essere inviato al repository principale una volta ultimata l’attività.

Tradizionalmente, quando si usa Git per sviluppare, è bene utilizzare il branch chiamato master solo per i rilasci di software definitivo e testato; utilizzando un branch chiamato -ad esempio-develop, è possibile salvare anche lavori ancora in via di definizione.

Con GitFlow, invece avere un uso centralizzato di develop, è possibile utilizzare questo branch come “genitore” delle future features: quando una funzionalità è completa, viene unita al branch develop.

Come si vede nella figura seguente, a partire dal ramo master vengono sviluppate due features tra la versione 0.1 e la 0.2: in quei due rami, gli sviluppatori effettuano diversi commit all’interno della propria feature; chiaramente, lo sviluppatore continua a ricevere eventuali aggiornamenti dagli altri branch (effettuando un merge), ma può intanto lavorare in parallelo alla propria.

Una volta chiuso il proprio task, è possibile procedere alla pubblicazione della propria feature sul ramo develop.

Esempio di come funziona GitFlow nella gestione delle features

Benefici

Sviluppo in parallelo

Uno dei vantaggi principali di GitFlow è che rende lo sviluppo parallelo molto semplice, isolando il nuovo sviluppo di una certa feature dal lavoro già concluso.

Il nuovo sviluppo (come lavoro sulle funzionalità e correzioni di bug non di emergenza) viene eseguito nei rami per le feature e viene unito di nuovo nel ramo principale del codice solo quando lo sviluppatore è sicuro che il codice sia pronto per il rilascio.

Collaborazione

I branch basati su_feature_ rendono inoltre più facile per due o più sviluppatori collaborare alla stessa funzionalità, perché ogni feature viene racchiusa in un branch che è come una sandbox in cui le uniche modifiche sono le modifiche necessarie per far funzionare la nuova funzionalità.

Ciò rende molto facile vedere e seguire ciò che ogni collaboratore sta facendo.

Come funziona

Supponiamo di avere un repository chiamato myrepo: eseguiamo i seguenti comandi per creare (se non c’è già) il branch develop e per iniziare a lavorare ad una nuova feature chiamata my_feature:

$ git flow init

$ git flow feature start my_feature

Una volta che il lavoro è stato completato, posso eseguire il seguente comando per effettuare il merge con il ramo develop:

$ git flow feature finish my_feature

Se poi stiamo lavorando in collaborazione con altre persone, possiamo pubblicare la feature eseguendo il primo comando, oppure recuperare eventuali funzionalità pubblicate eseguendo il secondo:

$ git flow feature publish my_feature 
$ git flow feature pull origin my_feature

Attenzione però: GitFlow non lavora solo con le features, ma anche con i rilasci e le situazioni di emergenza: infatti, è possibile utilizzare gli stessi comandi visti in precedenza sostituendo la parola release e hotfix al posto di feature, dove nel primo caso si lavora alla preparazione di una nuova versione da rilasciare in produzione oppure per correggere eventuali bug minori, mentre nel secondo caso si ripara a bug che devono essere risolti immediatamente.

Tip

Se non ricordi tutti i comandi e hai bisogno di un cheatsheet, puoi scaricarlo da qui! E se ancora avessi dei dubbi, qui c’è tutta la roadmap di come lavorare con feature, rilasci e fix creata da Daniel Kummer.

Risorse utili

• Letture consigliate: Docker (disponibile su Amazon)
• Canale di Emmecilab