Git Flow: Il Workflow di Branching Professionale
Git Flow è un modello di branching per Git che definisce una struttura rigorosa di branch progettata per gestire progetti di diverse dimensioni. Creato da Vincent Driessen, Git Flow è particolarmente adatto per progetti con release pianificate e team che lavorano su più funzionalità in parallelo.
🎯 Cosa Imparerai
- La struttura dei branch in Git Flow (main, develop, feature, release, hotfix)
- Come gestire feature, release e hotfix
- Naming conventions e best practices
- Quando usare Git Flow vs altri workflow
I Branch Principali
Git Flow usa due branch permanenti che vivono per tutta la durata del progetto:
main (o master):
- Contiene solo codice pronto per produzione
- Ogni commit è una release ufficiale
- Taggato con numero di versione (v1.0.0, v1.1.0, ecc.)
- Mai committare direttamente
develop:
- Branch di integrazione per nuove funzionalità
- Contiene l'ultimo stato di sviluppo
- Da qui partono i feature branch
- Base per le prossime release
# Inizia un nuovo progetto con Git Flow
git flow init
# O manualmente:
git checkout -b develop mainFeature Branches
I feature branch sono usati per sviluppare nuove funzionalità. Partono da
develop e vengono mergiati nuovamente in develop quando completati.
# Crea un nuovo feature branch
git flow feature start user-authentication
# Equivalente a:
# git checkout -b feature/user-authentication develop
# Lavora sulla feature
git add .
git commit -m "feat: add login form"
git commit -m "feat: add JWT authentication"
git commit -m "test: add auth tests"
# Finisci la feature (merge in develop e cancella il branch)
git flow feature finish user-authentication
# Equivalente a:
# git checkout develop
# git merge --no-ff feature/user-authentication
# git branch -d feature/user-authentication📝 Naming Convention per Feature
feature/user-authenticationfeature/payment-integrationfeature/dark-mode- Usa kebab-case
- Nomi descrittivi e concisi
Release Branches
I release branch supportano la preparazione di una nuova release in produzione.
Permettono bug fix minori e preparazione dei metadati (versione, build date) mentre il team
continua a lavorare su develop.
# Crea release branch da develop quando le feature sono pronte
git flow release start 1.2.0
# Equivalente a:
# git checkout -b release/1.2.0 develop
# Bug fix e preparazione release
git commit -m "chore: bump version to 1.2.0"
git commit -m "fix: correct typo in welcome message"
git commit -m "docs: update changelog"
# Finisci la release (merge in main E develop, tag su main)
git flow release finish 1.2.0
# Equivalente a:
# git checkout main
# git merge --no-ff release/1.2.0
# git tag -a v1.2.0
# git checkout develop
# git merge --no-ff release/1.2.0
# git branch -d release/1.2.0
# Pusha main, develop e i tag
git push origin main develop --tags⚙️ Cosa Fare nel Release Branch
- ✅ Bug fix minori
- ✅ Aggiornare numero di versione
- ✅ Preparare changelog
- ✅ Build di produzione e test finali
- ❌ Nuove feature (vanno in develop)
Hotfix Branches
Gli hotfix branch sono per correggere bug critici in produzione che non possono
aspettare la prossima release. Partono da main e vengono mergiati in main
E develop.
# Bug critico in produzione! (main è alla v1.2.0)
git flow hotfix start 1.2.1
# Equivalente a:
# git checkout -b hotfix/1.2.1 main
# Correggi il bug
git commit -m "fix: resolve critical payment bug"
# Finisci l'hotfix (merge in main e develop, tag su main)
git flow hotfix finish 1.2.1
# Equivalente a:
# git checkout main
# git merge --no-ff hotfix/1.2.1
# git tag -a v1.2.1
# git checkout develop
# git merge --no-ff hotfix/1.2.1
# git branch -d hotfix/1.2.1
# Deploy immediato in produzione
git push origin main develop --tagsEsempio Completo: Ciclo di Sviluppo
Vediamo un workflow completo dal feature development alla produzione:
# Setup iniziale
git flow init
# Crea branch: main, develop
# Sprint 1: Due sviluppatori lavorano su feature diverse
# Developer 1:
git flow feature start shopping-cart
# ... lavoro ...
git commit -m "feat: add cart component"
git flow feature finish shopping-cart
# Developer 2:
git flow feature start user-profile
# ... lavoro ...
git commit -m "feat: add profile page"
git flow feature finish user-profile
# Entrambe le feature sono ora in develop
# Prepara release
git flow release start 1.0.0
git commit -m "chore: bump version to 1.0.0"
git commit -m "docs: update README"
git flow release finish 1.0.0
# main ora è alla v1.0.0, deploy in produzione
# Bug critico trovato in produzione!
git flow hotfix start 1.0.1
git commit -m "fix: cart total calculation error"
git flow hotfix finish 1.0.1
# main ora è alla v1.0.1, hotfix deployato
# Nel frattempo, develop continua con nuove feature
git checkout develop
git flow feature start payment-gateway
# ... sviluppo continua ...Best Practices per Git Flow
✅ Do's
- Usa
--no-ffper i merge (mantiene storia dei branch) - Tagga sempre le release su main
- Scrivi messaggi di commit descrittivi (Conventional Commits)
- Testa prima di finire feature/release
- Pusha develop e main regolarmente
- Usa Pull Request per code review prima di finish
❌ Don'ts
- Non committare direttamente su main o develop
- Non tenere feature branch aperti troppo a lungo
- Non includere nuove feature nei release branch
- Non dimenticare di mergeare hotfix in develop
- Non usare Git Flow se fai continuous deployment
Naming Conventions
Convenzioni di naming chiare aiutano il team a capire lo scopo di ogni branch:
# Feature branches
feature/user-authentication
feature/api-integration
feature/responsive-navbar
# Release branches
release/1.0.0
release/2.1.0
release/3.0.0-beta
# Hotfix branches
hotfix/1.0.1
hotfix/2.1.3
hotfix/security-patch-3.0.1Quando Usare Git Flow
✅ Usa Git Flow se:
- Hai release pianificate (non continuous deployment)
- Supporti multiple versioni in produzione
- Hai un team grande con molte feature parallele
- Serve processo rigoroso per stabilità
❌ Evita Git Flow se:
- Fai continuous deployment (usa GitHub Flow)
- Hai un team piccolo (< 3 persone)
- Il progetto è semplice o prototipo
- Deploy multipli al giorno
Alternative a Git Flow
Git Flow non è l'unico workflow. Ecco le alternative:
- GitHub Flow: Più semplice, solo main + feature branch, per continuous deployment
- GitLab Flow: Ibrido tra Git Flow e GitHub Flow, con environment branches
- Trunk-Based Development: Tutti committano su main/trunk con feature flags
Strumenti per Git Flow
# macOS
brew install git-flow
# Linux (Ubuntu/Debian)
sudo apt-get install git-flow
# Windows (Git Bash)
# Download da: https://github.com/petervanderdoes/gitflow-avh
# Verifica installazione
git flow versionConclusione
Git Flow è un workflow potente per team che gestiscono release pianificate e multiple versioni in produzione. La sua struttura rigorosa porta disciplina e prevedibilità, ma può essere eccessiva per progetti semplici o team che fanno continuous deployment. Scegli Git Flow se la stabilità e il processo strutturato sono priorità.
🎯 Punti Chiave
- Due branch permanenti: main (produzione) e develop (integrazione)
- Feature branch per nuove funzionalità
- Release branch per preparare release
- Hotfix branch per bug critici in produzione
- Ideale per release pianificate e team grandi