git-flow: il modello di git workflow che utilizzo

Dopo aver letto l’interessante presentazione “How GitHub uses GitHub to build GitHub“, ho deciso di dare un’occhiata al modello di workflow chiamato git-flow [che si basa, ovviamente, sull’utilizzo di git].
In sintesi:

• Ci sono due branch sempre presenti: master e develop:
  • master contiene tutti i commit per cui il repo è deployabile in produzione [production ready].
  • develop contiene il codice di integrazione. Va da sé che una volta che il codice di integrazione è pronto, viene fatto un merge verso master.
• Ci sono alcuni branch che vengono creati/distrutti all’occorrenza: feature, release e hotfix:
  • feature è un branch di develop che contiene, appunto, alcune features“locali” al brach di sviluppo di cui verrà fatto il merge verso develop
  • release: una volta che il branch develop ha abbastanza features per una release, si crea un branch di develop per prepararsi ad un ciclo di rilascio. Nessuna nuova feature può essere introdotta a partire da questo branch. Una volta pronto, il branch release viene merge-ato al branch master [e successivamente al branch develop].
  • hotfix contiene, come dice il nome, delle fix urgenti che hanno origine nel branch di produzione, e di cui verrà fatto il merge nella prossima release di produzione [e che saranno riflesse, di conseguenza, anche in develop].

Può sembrare complicato: ecco un grafico che spiega in forma grafica quello che ho illustrato a parole:

Se volete saperne di più, sul sito di dell’ideatore è presente una descrizione più dettagliata di git flow.
Bonus: su GitHub è presente un’estensione per utilizzare git-flow direttamente da git.

Esistono anche altri modelli di workflow per git, ma a mio avviso, git-flow rimane il più indicato [per i miei progetti].