//FIXME: nelle figure il naming origin/prod = origin/stable//

====== Sviluppo e gestione release ======

Questo documento contiene le guideline per il branching model e lo sviluppo collaborativo dei software beFair.

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

Sul repo git di GF o degli altri software beFair (origin) ci sono due branch principali:
  - **origin/stable** è 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. Ogni merge viene taggato con un numero di versione. Se proprio ci fossero problemi, si può rollbackare al tag immediatamente precedente. La funzionalità fondamentale del branch stable è il **continuous delivery in produzione**.
    - Da origin/stable si brancha solo origin/master.
    - Su origin/stable si mergia solo da origin/master
    - Convenzione di naming per il -m dei commit: <numero_di_versione>, con, come detto, l'aggiunta di una tag con lo stesso nome. Usiamo http://semver.org come standard per il versionamento
  - **origin/master** è 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''. La funzionalità fondamentale del branch stable è il **continuous delivery in staging**.
    - Da origin/master si branchano tutti i branch descritti sotto
    - Su origin/master si mergia da tutti gli altri branch, escluso origin/stable

{{:dev:main-branches.png?200|}}

Ogni sviluppatore clona sulla sua macchina i due branch principali di origin. In base alle necessità, può creare branch secondo lo schema seguente:
  - **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.
    - Si brancha da origin/master
    - Si mergia su origin/master usando sempre e soltanto --no-ff (lo so, lo so, ma qui ha molti più pro che contro)
    - Convenzione di naming: ''feature-<nome_descrittivo_della_feature>''

{{:dev:feature-branches2.png?200|}}

  - **Bugfix branch**: identici ai feature branch, ma destinati a fixare bug di codice non ancora mergiato in ''origin/stable''
    - Convenzione di naming: ''bugfix-<numero_bug>''

  - **Hotfix branch**: è dove si fixano bug severi del codice già andato in produzione.
    - Si brancha da ''origin/stable''
    - Si mergia su ''origin/stable'' e ''origin/master'' con --no-ff
    - Convenzione di naming: ''hotfix-<versione>'' con il field PATCH aumentato di 1

{{:dev:main-branches.png?200|}}