Esplora E-book
Categorie
Esplora Audiolibri
Categorie
Esplora Riviste
Categorie
Esplora Documenti
Categorie
Introduzione
Git flow è un’estensione di git che offre comandi di alto livello sul repository basandosi sul modello
di branching di Vincent Driessen.
Definisce un modello di branching rigoroso che rispecchia le fasi di rilascio del progetto.
Come lavora
Il git flow come altri modelli usa un repository centrale usato come hub di comunicazione fra tutti
gli sviluppatori.
Ogni sviluppatore lavora sulla propria copia locale e pusha i branch sul repository centrale.
master
develop
che definiscono la storia del progetto. Entrambi sono presenti sul repository remoto al fine di essere
condivisi con l’intero team.
Tutti gli sviluppi paralleli da parte dei team vengono gestiti tramite branch di supporto , in modo da
tenere traccia di nuove funzionalità, fix veloci, etc…
Abbiamo 3 tipi di branch di supporto:
feature
release
hotfix
ognuno di questi ha uno scopo specifico e hanno regole rigide come ad esempio il ramo originario,
il ramo in cui vengono fusi, etc. I branch di supporto non necessariamente devono essere presenti
sul repository remoto se non per backup/collaborazione. La distinzione principale su quale branch
usare e sul modo in cui vengono usati.
Setup
Installazione
# OSx
$ brew install git-flow-avh
# Linux
$ apt-get install git-flow
# Windows
$ wget -q -O - --no-check-certificate
https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-
installer.sh install stable | bash
Inizializzazione
$ git flow init
Which branch should be used for bringing forth production releases?
- develop
- master
Branch name for production releases: [master]
Which branch should be used for integration of the "next release"?
- develop
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
origin/master è il ramo principale in cui la HEAD riflette sempre lo stato della produzione, archivia
quindi la storia ufficiale del progetto.
origin/develop è il ramo principale in cui la HEAD riflette lo stato delle ultime modifiche di
sviluppo e serve da branch di integrazione per tutti le feature.
E buona norma usare i tag per tutti i commit sul branch master usando un sistema di versionamento
(per maggiori dettagli sul versionamento http://semver.org/lang/it/).
Feature
In generale sono usate per sviluppare nuove funzionalità per il medio-lungo periodo. La feature
esiste finchè c’è lo sviluppo, essendo un ramo a sè stante può venire mergiata oppure abbandonata.
Quando la feature è completa viene mergiata sul develop, le feature quindi non hanno mai
interazione diretta con il master.
Branch di origine: develop
Branch di fusione: develop
Branch naming: tutto ad esclusione di master, develop, release-*, hotfix-*
Release
Le release servono come supporto alla preparazione di una nuova release in produzione, inoltre
consentono la correzione di bug dell’ultimo minuto e la preparazione dei metadati per il rilascio
(numero di versione, date, etc).
Facendo queste operazioni su un ramo a parte, il ramo di sviluppo (develop) è libero di ricevere
nuovo codice per una futura release.
Hotfixes
I branch di maintenance (hotfix) sono usati per sviluppare patch sul codice di produzione.
E’ l’unico tipo di branch che forca direttamente dal branch master. Alla fine della fix mergia
direttamente su develop e master e il master viene taggato con un aggiornamento di numero di
versione.
Dal momento che ha una sua linea dedicata di sviluppo, può essere rilasciato velocemente senza
dover interrompere il flusso o aspettare una nuova release.
Comandi principali
Feature
crea un nuovo branch basato sul develop e switcha sul branch stesso.
Terminare una nuova feature
Release
Hotfixes
crea un nuovo branch basato sul develop e switcha sul branch stesso.
merge della hotfix sul develop e sul master, il master viene taggato con la versione della hotfix