Un efficace flusso di lavoro per Git

In un articolo piuttosto famoso e non certo nuovissimo, Vincent Driessen presenta quello che è un efficace e robusto workflow per la gestione di progetti con Git. Il sistema ha incontrato tanto successo che è stato poi anche scritta un'estensione di Git stesso proprio per applicare questo modello in modo più immediato. L'estensione si chiama gitflow e si trova su github (se usarla o meno è poi questione di gusti: personalmente preferisco fare comunque tutto a mano).

Sia chiaro che si parla di niente di fantasmagorico: è solo una raccolta di "best practice" e convenzioni fatte per rendere più coordinato e fluido il lavoro del nostro team di sviluppo.

Senza entrare troppo nei dettagli, per i quali vi rimando all'articolo, cerchiamo di capire di che si tratta.

Il sistema prevede l'utilizzo di due rami principali, presenti fin dall'inizio del vostro progetto: uno è quello di "produzione", ovvero il branch MASTER mentre l'altro è il ramo di sviluppo ovvero DEVELOP (il maiuscolo per il nome dei branch è una mia licenza).

Il ramo MASTER del progetto di produzione viene aggiornato (via pull) soltanto quando ci sono modifiche che sono state pienamente testate. Sul ramo DEVELOP procedono invece le normali operazioni di sviluppo del team. Da questo ramo possono prendere ovviamente vita altri rami (i cosiddetti topic / feature branch) che possono essere creati in ogni momento dagli sviluppatori con il nome che meglio credono.

Non appena si avvicina il momento di produrre un nuovo rilascio in produzione, dal ramo DEVELOP viene creato un ramo che si chiama RELEASE-qualcosa. Il "qualcosa" dipende da voi, non è importante e può essere qualcosa tipo "3.1". Lo scopo dei rami RELEASE è quello di essere sicuri che sia stato effettuato prima di tutto un "feature freeze" del progetto (mentre su DEVELOP lo sviluppo può continuare allegramente...) e comunque sia ancora possibile per qualche tempo fare piccole modifiche o correggere bachi sul codebase che sta per diventare la nuova release.

Ad un certo punto il ramo RELEASE-3.1 verrà  finalmente unito (via merge) al ramo MASTER. Il commit del merge potrà  magari essere identificato (via tag). Il ramo RELEASE-* viene poi unito anche dentro DEVELOP (perché potrebbe contenere piccole modifiche) e infine rimosso.

Qualora si dovesse presentare un grave baco in produzione, o fosse il momento di correggerne alcuni di una certa rilevanza (una cosiddetta "bug fixing release") si crea un ramo HOTFIX-* per correggerlo. Questo ramo concettualmente è praticamente uguale ai rami RELEASE (in effetti potrebbe alla fine creare una nuova release, come la 3.1.1), ma deve essere creato dal ramo MASTER perché in questo modo è più semplice affidare la correzione ad una persona, mentre il resto del team lavora, modificandolo, sul ramo DEVELOP il quale oltretutto potrebbe essere ancora troppo instabile per poter creare un altro ramo RELEASE che incorpora le correzioni dei bug.

Come per i branch RELEASE anche gli HOTFIX verranno poi inclusi sia in MASTER che in DEVELOP. Ancora una volta è consigliato applicare un tag al commit di merge sul MASTER.