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 feature locali al branch di sviluppo, di cui verrà fatto il merge verso develop.
    • release: una volta che il branch develop ha abbastanza feature 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 unito 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 esplicativo:

Se volete saperne di più, sul sito 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.