Heading

Gitflow Workflow è un workflow Git che aiuta lo sviluppo continuo del software e l’implementazione delle pratiche DevOps. È stato pubblicato per la prima volta e reso popolare da Vincent Driessen a nvie. Il Gitflow Workflow definisce un rigido modello di branching progettato intorno al rilascio del progetto. Questo fornisce un quadro robusto per la gestione di progetti più grandi.

Gitflow è ideale per progetti che hanno un ciclo di rilascio programmato e per la best practice DevOps della consegna continua. Questo workflow non aggiunge nessun nuovo concetto o comando oltre a quello richiesto dal Feature Branch Workflow. Invece, assegna ruoli molto specifici ai diversi rami e definisce come e quando dovrebbero interagire. Oltre ai rami feature, utilizza singoli rami per la preparazione, la manutenzione e la registrazione dei rilasci. Naturalmente, si possono anche sfruttare tutti i benefici del Feature Branch Workflow: richieste di pull, esperimenti isolati e collaborazione più efficiente.

Per iniziare

Gitflow è davvero solo un’idea astratta di un flusso di lavoro Git. Questo significa che detta il tipo di rami da impostare e come fonderli insieme. Toccheremo gli scopi dei rami più avanti. Il set di strumenti git-flow è un vero e proprio strumento a riga di comando che ha un processo di installazione. Il processo di installazione di git-flow è semplice. I pacchetti per git-flow sono disponibili su diversi sistemi operativi. Sui sistemi OSX, è possibile eseguire brew install git-flow. Su windows dovrete scaricare e installare git-flow. Dopo aver installato git-flow potete usarlo nel vostro progetto eseguendo git flow init. Git-flow è un wrapper intorno a Git. Il comando git flow init è un’estensione del comando predefinito git init e non cambia nulla nel vostro repository oltre a creare rami per voi.

Come funziona

Rami di sviluppo e master

Invece di un singolo master ramo, questo flusso di lavoro usa due rami per registrare la storia del progetto. Il ramo master memorizza la storia del rilascio ufficiale, e il ramo develop serve come ramo di integrazione per le funzionalità. È anche conveniente etichettare tutti i commit nel ramo master con un numero di versione.

Il primo passo è quello di integrare il master di default con un develop ramo. Un modo semplice per farlo è che uno sviluppatore crei un ramo vuoto develop localmente e lo spinga sul server:

git branch develop
git push -u origin develop

Questo ramo conterrà la storia completa del progetto, mentre master conterrà una versione ridotta. Gli altri sviluppatori dovrebbero ora clonare il repository centrale e creare un ramo di tracciamento per develop.

Quando si usa la libreria di estensione git-flow, eseguendo git flow init su un repo esistente verrà creato il ramo develop:

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: 
Branch name for "next release" development: 
How to name your supporting branch prefixes?
Feature branches? 
Release branches? 
Hotfix branches? 
Support branches? 
Version tag prefix? 
$ git branch
* develop
master

Feature Branches

Ogni nuova feature dovrebbe risiedere nel proprio ramo, che può essere spinto al repository centrale per il backup/collaborazione. Ma, invece di ramificare da master, i rami feature usano develop come ramo padre. Quando una caratteristica è completa, viene fusa di nuovo in develop. Le feature non dovrebbero mai interagire direttamente con master.

Nota che i rami feature combinati con il ramo develop sono, a tutti gli effetti, il Feature Branch Workflow. Ma il Gitflow Workflow non si ferma qui.

Feature i rami sono generalmente creati a partire dall’ultimo develop ramo.

Creare un ramo feature

Senza le estensioni git-flow:

git checkout develop
git checkout -b feature_branch

Quando si usa l’estensione git-flow:

git flow feature start feature_branch

Continuare il proprio lavoro e usare Git come si farebbe normalmente.

Finire il ramo di una caratteristica

Quando hai finito il lavoro di sviluppo sulla caratteristica, il prossimo passo è quello di unire il feature_branch in develop.

Senza le estensioni git-flow:

git checkout develop
git merge feature_branch

Usando le estensioni git-flow:

git flow feature finish feature_branch

Rami di rilascio

Una volta che develop ha acquisito abbastanza caratteristiche per un rilascio (o una data di rilascio predeterminata si avvicina), si crea un release ramo da develop. La creazione di questo ramo avvia il prossimo ciclo di rilascio, quindi nessuna nuova caratteristica può essere aggiunta dopo questo punto – solo correzioni di bug, generazione di documentazione e altri compiti orientati al rilascio dovrebbero andare in questo ramo. Una volta che è pronto per la spedizione, il ramo release viene fuso in master e contrassegnato con un numero di versione. Inoltre, dovrebbe essere unito di nuovo in develop, che potrebbe essere progredito da quando il rilascio è stato iniziato.

Utilizzare un ramo dedicato per preparare i rilasci rende possibile per un team di perfezionare il rilascio corrente mentre un altro team continua a lavorare sulle caratteristiche per il prossimo rilascio. Crea anche fasi di sviluppo ben definite (ad esempio, è facile dire, “Questa settimana stiamo preparando la versione 4.0,” e vederlo effettivamente nella struttura del repository).

Fare rami release è un’altra operazione di ramificazione diretta. Come i rami feature, i rami release si basano sul ramo develop. Un nuovo release ramo può essere creato utilizzando i seguenti metodi.

Senza le estensioni git-flow:

git checkout develop
git checkout -b release/0.1.0

Quando si usano le estensioni git-flow:

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Una volta che il rilascio è pronto per la spedizione, verrà unito in master e develop, poi il ramo release verrà cancellato. È importante fondere nuovamente in develop perché gli aggiornamenti critici possono essere stati aggiunti al ramo release e devono essere accessibili alle nuove funzionalità. Se la vostra organizzazione sottolinea la revisione del codice, questo sarebbe un posto ideale per una richiesta di pull.

Per finire un release ramo, usa i seguenti metodi:

Senza le estensioni git-flow:

git checkout master 
git merge release/0.1.0

O con l’estensione git-flow:

git flow release finish '0.1.0'

Hotfix Branches

I rami di manutenzione o "hotfix” sono usati per patchare rapidamente i rilasci di produzione. I rami Hotfix sono molto simili ai rami release e feature tranne che sono basati su master invece di develop. Questo è l’unico ramo che dovrebbe uscire direttamente da master. Non appena la correzione è completa, dovrebbe essere fusa sia in master che in develop (o nell’attuale release ramo), e master dovrebbe essere contrassegnato con un numero di versione aggiornato.

Avere una linea di sviluppo dedicata alla correzione dei bug permette al vostro team di affrontare i problemi senza interrompere il resto del flusso di lavoro o aspettare il prossimo ciclo di rilascio. Si può pensare ai rami di manutenzione come rami ad hoc release che lavorano direttamente con master. Un hotfix ramo può essere creato utilizzando i seguenti metodi:

Senza le estensioni git-flow:

git checkout master
git checkout -b hotfix_branch

Quando si utilizzano le estensioni git-flow:

$ git flow hotfix start hotfix_branch

Simile a finire un release ramo, un hotfix ramo viene fuso sia in master che in develop.

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

Esempio

Un esempio completo che dimostra un Feature Branch Flow è il seguente. Supponendo di avere un repo impostato con un ramo master.

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

In aggiunta ai flussi feature e release, un esempio hotfix è il seguente:

git checkout master
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

Riassunto

Qui abbiamo discusso il Gitflow Workflow. Gitflow è uno dei molti stili di flussi di lavoro Git che voi e il vostro team potete utilizzare.

Alcuni elementi chiave da sapere su Gitflow sono:

• Il flusso di lavoro è ottimo per un flusso di lavoro software basato sul rilascio.
• Gitflow offre un canale dedicato per gli hotfix alla produzione.

Il flusso complessivo di Gitflow è:

1. Un develop ramo viene creato da master
2. Un release ramo viene creato da develop
3. Feature rami sono creati da develop
4. Quando un feature è completo viene unito al develop ramo
5. Quando il release è completato viene fuso in develop e master
6. Se un problema in master viene rilevato un hotfix viene creato da master
7. Una volta che il hotfix è completo viene unito ad entrambi develop e master

Il prossimo, scopri il Forking Workflow o visita la nostra pagina di confronto dei flussi di lavoro.