Git - git modelli di branching

Git – modelli di branching

Partendo da un articolo scritto nel 2010 da  Vincent Driessen  e disponibile a questo indirizzo  prendo spunto per alcune considerazione sull’approccio al branching in Git.

Alla base dell’articolo c’è l’idea di poter definire uno standard per definire il ciclo di sviluppo dei rami dev, hotfix e release. Il tutto sfruttando le potenzialità dei branch.

Perchè definire uno standard nel modello di braching ?

La riposta è da ricercare nei vantaggi che se ne può trarre, e più precisamente:

  • le procedure sono più chiare e leggibili
  • il repository cresce in maniera ordinata
  • se il modello adottato è un modello comune, è più semplice aggiungere nuovi sviluppatori
  • se il modello adottato è un modello comune, è più semplice passare da un progetto all’altro, rispettando le stesse convenzioni

Modello di branching (Git-flow)

Il modello Git-Flow utilizzato in Source è quello che maggiormente rispetta lo standard che cerco di adottare nello sviluppo di soluzioni (anche perchè fa parte del template predefinito). Vediamo ora quali sono i branch che non possono mancare:

  • Development branch (develop): è il ramo di sviluppo principale, in cui vengono committati tutti i cambiamenti che saranno introdotti nella nuova versione del sofware in sviluppo. Questo branch viene alimentato da piccole modifiche o parti di altri branch (es. branch di funzionalità)
  • Produzione (master): è il branch della versione corrente del codice. Viene alimentato solo da altri branch
  • Features branch (features/): tipicamente vengono preceduti dal features/ . Quando si inizia a sviluppare una nuova funzionalità viene creato un nuovo branch features, che verrà unito con il branch develop solo al termine dell’implementazione, in modo da metterlo in coda nella prossima versione
  • Release branch (release/): ogni volta che una nuova release è pronta per essere integrata all’interno del branch di produzione, è necessario creare un nuovo branch release, a partire dal ramo di sviluppo (develop). Quando il nostro progetto è pronto per essere rilasciato, lo si unisce al branch master e al branch develop per indicare che è stato distribuito
  • Branch di aggiornamento rapido (hotfix/): nel caso in cui si renda necessario realizzare patch della versione in produzione, non è necessario modificare il ramo di sviluppo ma è sufficiente creare un nuovo branch di master. Dopo aver risolto il problema, il ramo hotfix viene unito al branch master (per aggiornare la versione in produzione) e al branch develop (per renderlo disponibile agli altri sviluppatori e per assicurarsi che le modifiche siano incluse all’interno delle prossime versioni).

Questo tipo di approccio può rivelarsi troppo semplice nella gestione di progetti complessi, ma sicuramente essere d’aiuto in piccoli team di lavoro.

 

Pubblicato da

Andrea Merlin

Laureato in informatica, diversi corsi di specializzazione legati allo Sviluppo Software e alla Computer forensics. Appassionato di nuove tecnologie, amo la programmazione, la Business Intelligence e tematiche legate alla Privacy.Sempre alla ricerca di nuove idee, stimoli … e progetti da seguire!Amo trascorrere il tempo libero in Val Borbera, un piccolo angolo del Piemonte, in provincia di Alessandria.