Come abbiamo imparato nella nostra guida Git, il branch master è il centro del nostro progetto, perché rispecchia la versione pubblica attualmente in produzione, la versione cioè accessibile ai nostri utenti. Se il nostro progetto fosse una App, essa rispecchierebbe la versione attualmente scaricabile dal Play Store o App Store.

L’approccio GitFlow utilizza due rami principali per gestire il controllo di versione (versioning) del progetto. Il primo, master che conserva, come detto, tutte le release. Il secondo è il ramo develop, che è fondamentale per lo sviluppo delle prossime versione e serve come base per le future integrazioni che vedremo nei vari capitoli. È inoltre conveniente taggare tutti i commit (o merge) verso il master con un numero di versione progessiva.

Tutta la (futura) vita del nostro progetto ruoterà quindi attorno ai due rami  master  e develop  ed essi saranno il punto di partenza e di arrivo degli altri rami e saranno l’ossatura vera e propria del repository.

Cominciamo. Allo stato iniziale del nostro progetto, se non utilizziamo ancora GitFlow, non avremo un ramo develop, perciò dovremmo crearlo a partire da quello master . Vediamo come fare:

A questo punto, se ci fossero altri sviluppatori, dovrebbero clonare e fare il track di questo ramo per l’integrazione di nuove funzioni.

Come ci siamo detti nell’introduzione a GitFlow, i comandi git-flow sono una forma abbreviata di uno o più comandi git . Il comando git flow init controllerà l’esistenza dei rami master e develop per noi e li creerà automaticamente nel caso non ci fossero. Lasciamo pure le impostazioni di default: