Questo documento riassume la gestione dello sviluppo per i software beFair. Il documento si riferisce al repository cosiddetto “origin” cui tutti i contributori al codice fanno riferimento per portare avanti lo sviluppo.

Se si desidera conoscere il workflow di sviluppo beFair, basato sul modello a fork, si consulti il documento git-forking-workflow

1. il ramo principale di sviluppo è il master
2. ogni release rilasciata viene taggata con rel-$ver$extra dove:
   1. $ver è il numero di versione seguendo http://semver.org (MAJOR.MINOR.PATCH)
   2. $extra può essere -dev, -beta, -rcX, o omesso in caso di release stable
3. per i bugfix rilasciati su una specifica versione stabile, verrà creato un branch dalla release opportuna con nome rel-$ver-fix. Al rilascio a sua volta verrà assegnata una release specifica con MINOR version + 1 e verrà quindi elminato il branch -fix;
4. ogni feature che lo necessita può essere sviluppata in un branch di nome feat-$featname dove $featname è il nome della feature; una volta integrato nel master, il branch deve essere eliminato;

Sul repo git di GF (origin) ci sono due branch principali:

1. origin/prod è il branch dove HEAD corrisponde sempre a codice pronto per il deploy in produzione. In altre parole, ogni commit ha superato tutti i test ed è deployable in produzione. In caso di problemi, si può rollbackare al commit immediatamente precedente.
   1. Da origin/prod si brancha solo origin/dev.
   2. Su origin/prod si mergia solo da origin/dev
   3. Convenzione di naming per i commit: <numero_di_versione>, con l'aggiunta di una tag con lo stesso nome. Usiamo semver.org come standard per il versionamento
2. origin/dev è il branch principale di sviluppo dove vengono mergiati tutti gli altri branch descritti sotto. E' anche usato per committare eventuali piccole modifiche necessarie per la release. In altre parole, è un integration branch ed anche release finalization branch.
   1. Da origin/dev si branchano tutti i branch descritti sotto
   2. Da origin/dev si mergia da tutti gli altri branch, escluso origin/prod

Ogni sviluppatore clona sulla sua macchina i due branch principali di origin. In base alle necessità, può creare branch secondo lo schema seguente:

1. Feature branch: è dove si sviluppa una nuova feature. Tipicamente esiste solo sulla macchina dello sviluppatore, ma si può pushare sul repo per lavoro di team o se serve una review del codice.
   1. Si brancha da origin/dev
   2. Si mergia su origin/dev usando sempre e soltanto –no-ff (lo so, lo so, ma qui ha molti più pro che contro)
   3. Convenzione di naming: feature-<nome_descrittivo_della_feature>
2. Bugfix branch: identici ai feature branch, ma destinati a fixare bug di codice non ancora mergiato in origin/prod
   1. Convenzione di naming: bugfix-<numero_bug>
3. Hotfix branch: è dove si fixano bug severi del codice già andato in produzione.
   1. Si brancha da origin/prod
   2. Si mergia su origin/prod e origin/dev con –no-ff
   3. Convenzione di naming: hotfix-<versione> con il field PATCH aumentato di 1