Introduzione

Git flow è un’estensione di git che offre comandi di alto livello sul repository basandosi sul modello di branching di Vincent Driessen.
Definisce un modello di branching rigoroso che rispecchia le fasi di rilascio del progetto.

Come lavora

Il git flow come altri modelli usa un repository centrale usato come hub di comunicazione fra tutti gli sviluppatori.
Ogni sviluppatore lavora sulla propria copia locale e pusha i branch sul repository centrale.

Il modello sopra descritto si compone di due branch principali:

• master
• develop

che definiscono la storia del progetto. Entrambi sono presenti sul repository remoto al fine di essere condivisi con l’intero team.

Tutti gli sviluppi paralleli da parte dei team vengono gestiti tramite branch di supporto , in modo da tenere traccia di nuove funzionalità, fix veloci, etc…
Abbiamo 3 tipi di branch di supporto:

• feature
• release
• hotfix

ognuno di questi ha uno scopo specifico e hanno regole rigide come ad esempio il ramo originario, il ramo in cui vengono fusi, etc. I branch di supporto non necessariamente devono essere presenti sul repository remoto se non per backup/collaborazione. La distinzione principale su quale branch usare e sul modo in cui vengono usati.

Setup

Installazione

L’unico requisito è avere git già installato (http://Guida all’installazione di Git)

# OSx
$ brew install git-flow-avh 
# Linux 
$ apt-get install git-flow
# Windows 
$ wget -q -O - --no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash

Inizializzazione

$ git flow init
Which branch should be used for bringing forth production releases?
- develop
- master
Branch name for production releases: [master]
Which branch should be used for integration of the "next release"?
- develop
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Struttura dei branch

Branch principali

origin/master è il ramo principale in cui la HEAD riflette sempre lo stato della produzione, archivia quindi la storia ufficiale del progetto.
origin/develop è il ramo principale in cui la HEAD riflette lo stato delle ultime modifiche di sviluppo e serve da branch di integrazione per tutti le feature.
E buona norma usare i tag per tutti i commit sul branch master usando un sistema di versionamento (per maggiori dettagli sul versionamento http://semver.org/lang/it/).

Feature

In generale sono usate per sviluppare nuove funzionalità per il medio-lungo periodo. La feature esiste finchè c’è lo sviluppo, essendo un ramo a sè stante può venire mergiata oppure abbandonata. Quando la feature è completa viene mergiata sul develop, le feature quindi non hanno mai interazione diretta con il master.

Branch di origine: develop
Branch di fusione: develop
Branch naming: tutto ad esclusione di master, develop, release-*, hotfix-*

Release

Le release servono come supporto alla preparazione di una nuova release in produzione, inoltre consentono la correzione di bug dell’ultimo minuto e la preparazione dei metadati per il rilascio (numero di versione, date, etc).
Facendo queste operazioni su un ramo a parte, il ramo di sviluppo (develop) è libero di ricevere nuovo codice per una futura release.

branch di origine: develop
branch di fusione: develop e master
branch naming: release-*

Hotfixes

I branch di maintenance (hotfix) sono usati per sviluppare patch sul codice di produzione.
E’ l’unico tipo di branch che forca direttamente dal branch master. Alla fine della fix mergia direttamente su develop e master e il master viene taggato con un aggiornamento di numero di versione.
Dal momento che ha una sua linea dedicata di sviluppo, può essere rilasciato velocemente senza dover interrompere il flusso o aspettare una nuova release.

branch di origine: master
branch di fusione: master e develop
tag: incrementa il patch number
branch naming: hotfix-* o hotfix/*

Comandi principali

Feature

Iniziare una nuova feature

$ git flow feature start nome_feature

crea un nuovo branch basato sul develop e switcha sul branch stesso.
Terminare una nuova feature

$ git flow feature finish nome_feature

esegue le operazioni di:

• merge dell branch sul develop
• cancellazione del branch
• switch sul branch develop

Pubblicare una feature

$ git push origin feature/nome_feature
# oppure
$ git flow feature publish nome_feature

permette di pubblicare in remoto una feature in caso di sviluppo condiviso
Scaricare una feature pubblicata

$ git checkout feature/nome_feature
#oppure
$ git flow feature pull origin nome_feature

per scaricare una feature pubblicata da un altro utente.

Release

Iniziare una release

$ git flow release start nome_release[BASE]

crea un nuovo branch basato sul develop e switcha sul branch stesso.
C’è la possibilità di fornire un ulteriore parametro [BASE] che è l’sha-1 hash del commit dal quale far partire la nuova release. Il commit deve essere sul branch develop.

Pubblicare una release

$ git push origin feature/nome_release
#oppure
$ git flow release publish nome_release

per pushare in remoto una feature in caso di sviluppo condiviso.
E’ buona norma pushare la release in modo da consentire anche da parte degli altri sviluppatori l’invio di release.

Terminare una release

$ git flow feature finish nome_release

esegue le operazioni di:

• merge della release sul branch develop
• tag della release con il suo nome (oppure versioning)
• merge all’indietro sul branch develop
• rimozione della release

Push dei tag

$ git push --tags

Push in remoto dei tag creati.

Hotfixes

Iniziare una hotfix

$ git flow hotfix start version_number

crea un nuovo branch basato sul develop e switcha sul branch stesso.

Terminare una hotfix

$ git flow hotfix finish

merge della hotfix sul develop e sul master, il master viene taggato con la versione della hotfix

Push dei tag

$ git push --tags

Push in remoto dei tag creati.

Bibliografia

http://danielkummer.github.io/git-flow-cheatsheet/index.it_IT.html
http://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com