Gitflow workflow

Panoramica

Gitflow è un modello di branching strutturato, reso popolare da Vincent Driessen nel 2010, progettato per progetti con rilasci pianificati e versionati. Invece di un singolo branch di integrazione, utilizza due branch longevi più tre tipi di branch di supporto, ciascuno con uno scopo definito. La struttura rende esplicita la gestione dei rilasci a fronte di una maggiore cerimonia.

I due branch longevi

Questi due branch vivono per l'intera durata del progetto — non vengono mai eliminati.

• main contiene il codice pronto per la produzione. Ogni commit su main corrisponde a una versione rilasciata e di solito è taggato (ad esempio v1.4.0). Se vuoi sapere esattamente cosa gira in produzione, fai il checkout di main.
• develop è il branch di integrazione dove le feature completate si accumulano tra un rilascio e l'altro. Contiene sempre le ultime modifiche destinate al prossimo rilascio, ma quelle modifiche non sono necessariamente ancora stabili.

Poiché entrambi i branch sono permanenti, la relazione tra loro non si azzera mai: develop è sempre "avanti" rispetto a main di tutto ciò che non è ancora stato rilasciato.

I tre branch di supporto

I branch di supporto sono di breve durata. Ognuno viene creato per uno scopo specifico, unito quando tale scopo è completato, e poi eliminato. Le convenzioni di denominazione (feature/, release/, hotfix/) rendono il loro ruolo immediatamente chiaro nell'output di git branch.

Branch feature

I branch feature si diramano da develop e vengono riportati in develop. Contengono il lavoro per le funzionalità future e non interagiscono mai direttamente con main — una singola feature non viene mai rilasciata da sola; viene distribuita come parte del prossimo rilascio versionato.

git switch develop
git switch -c feature/search   # create + check out feature/search
# ...work and commit...
git switch develop
git merge feature/search       # fold the feature into develop
git branch -d feature/search   # delete it once merged

Un git switch -c <name> crea il branch dal branch corrente e lo attiva in un solo passaggio — è l'equivalente moderno di git checkout -b. Consulta Git switch per il comando completo. Mantenere i branch feature di breve durata limita quanto si allontanano da develop, il che riduce i conflitti di merge.

Branch release

I branch release si diramano da develop quando è feature-complete per un rilascio. Esistono solo per la rifinitura finale — aggiornamenti di versione, note di rilascio e correzioni dell'ultimo minuto — mentre develop rimane aperto per le feature del prossimo ciclo.

Quando il rilascio è pronto, il branch viene unito in entrambi i luoghi:

• in main, dove viene taggato con il numero di versione; e
• di nuovo in develop, in modo che le eventuali correzioni di stabilizzazione effettuate sul branch release non vadano perse.

git switch -c release/1.4.0 develop
# ...bump version, fix last bugs, write release notes...
git switch main
git merge --no-ff release/1.4.0      # record an explicit merge commit
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0      # carry fixes back into develop
git branch -d release/1.4.0

--no-ff (no fast-forward) forza Git a creare un commit di merge anche quando un fast-forward sarebbe possibile, in modo che il rilascio sia preservato come un singolo punto visibile nella cronologia anziché essere appiattito.

Branch hotfix

I branch hotfix si diramano da main per correggere urgentemente un bug in produzione — senza attendere che il lavoro corrente su develop sia pronto per il rilascio. Come i branch release, vengono uniti sia in main (taggato con una versione patch aggiornata) sia in develop, in modo che la correzione sia presente anche nei rilasci futuri.

git switch -c hotfix/1.4.1 main
# ...fix the bug and commit...
git switch main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop
git merge --no-ff hotfix/1.4.1       # don't reintroduce the bug later
git branch -d hotfix/1.4.1

Dimenticare il secondo merge — di ritorno in develop — è il classico errore di Gitflow: il bug ricompare nel rilascio successivo perché la correzione è finita solo su main.

Quando usare Gitflow

Gitflow eccelle quando si distribuiscono rilasci distinti e versionati — applicazioni desktop, librerie, app mobile sottoposte alla revisione degli store, o qualsiasi cosa con numeri di versione gestiti e occasionali patch di emergenza. I branch release e hotfix espliciti offrono un posto chiaro dove stabilizzare e correggere la produzione senza disturbare lo sviluppo in corso. La necessità di supportare più versioni rilasciate contemporaneamente è il segnale più forte che la struttura di Gitflow ripagherà.

Un ciclo di rilascio completo in breve

Mettendo insieme tutti i pezzi, una versione attraversa i branch in questo modo:

1. Gli sviluppatori tagliano branch feature/* da develop, lavorano e li reintegrano uno per uno in develop.
2. Quando develop ha abbastanza per un rilascio, viene tagliato un branch release/x.y.0 per la stabilizzazione finale.
3. Il branch release viene unito in main, taggato vx.y.0, e riportato in develop.
4. Se la produzione si rompe, un branch hotfix/x.y.z si dirama da main, viene taggato e unito sia in main che in develop.

main avanza quindi solo attraverso merge di release e hotfix, e ogni commit su di esso è una versione distribuibile e taggata.

I compromessi

Quella struttura è anche il punto debole di Gitflow. I numerosi tipi di branch aggiungono overhead, e il branch develop longevo può allontanarsi molto da main, rendendo dolorosi i merge. I branch a lunga durata incoraggiano integrazioni grandi e poco frequenti — l'opposto di ciò che vuole la continuous delivery. I team che distribuiscono molte volte al giorno trovano di solito Gitflow troppo pesante e preferiscono il più semplice approccio a branch feature o trunk-based, dove il lavoro viene integrato continuamente in un unico branch. Scegli Gitflow quando la cadenza dei rilasci e il supporto parallelo delle versioni, non la velocità di distribuzione pura, sono le tue priorità.

Confrontalo con le alternative prima di impegnarti: il forking workflow per i contributi open-source, e i semplici feature branch per la maggior parte delle web app che effettuano il deploy da una singola linea.

Esercitazione