Git Workflow per Team Piccoli: Guida Pratica 2025

In un team di 2-5 sviluppatori, scegliere il workflow Git giusto può fare la differenza tra rilasci fluidi e ore perse in merge conflict. Troppo semplice e rischi di sovrascrivere codice. Troppo complesso e passi più tempo a gestire branch che a scrivere codice. Vediamo quali strategie funzionano davvero per team piccoli nel 2025.

Perché serve un workflow definito

Anche in un team di 3 persone, senza regole chiare succedono disastri:

• Push diretti su main che rompono la produzione
• Branch aperti da settimane che nessuno sa più cosa contengono
• Merge conflict enormi perché tutti hanno modificato gli stessi file
• Confusione su cosa è stato rilasciato e cosa no

Un workflow Git è un accordo su come collaborare: dove creare branch, quando fare merge, come rilasciare. Non serve che sia complesso—serve che tutti lo seguano.

Le tre strategie principali

1. GitFlow: il veterano strutturato

GitFlow è stato il primo workflow formalizzato, ancora usato in contesti enterprise e per software con versioni numerate.

Branch principali:
├── main (o master) → codice in produzione
└── develop → integrazione feature

Branch temporanei:
├── feature/nuova-funzione → sviluppo feature
├── release/v1.2.0 → preparazione rilascio
└── hotfix/bug-critico → fix urgenti in produzione

Come funziona

1. Crei feature/xxx da develop
2. Sviluppi e fai merge in develop
3. Quando pronto per il rilascio, crei release/v1.x
4. Test finali, poi merge in main e develop
5. Per hotfix: branch da main, fix, merge in entrambi

Pro e contro

• Pro: struttura chiara, versioning esplicito, adatto a release pianificate
• Contro: troppi branch, troppi merge, overhead per team piccoli

Verdetto per team piccoli: generalmente eccessivo. Usalo solo se hai release pianificate con versioni (v1.0, v1.1) e più ambienti (staging, produzione).

2. GitHub Flow: semplicità efficace

GitHub Flow è la versione semplificata: un solo branch principale e feature branch di breve durata.

Branch principali:
└── main → sempre deployabile

Branch temporanei:
└── feature/xxx → sviluppo, poi PR → main

Come funziona

1. Crei branch da main con nome descrittivo
2. Sviluppi, fai commit frequenti
3. Apri Pull Request quando pronto
4. Review del team, discussione, eventuali modifiche
5. Merge in main → deploy automatico

# Esempio tipico
git checkout main
git pull origin main
git checkout -b feature/login-google

# ... sviluppo ...

git push origin feature/login-google
# Apri PR su GitHub/GitLab

# Dopo approvazione
git checkout main
git pull origin main
git branch -d feature/login-google

Pro e contro

• Pro: semplice da capire, funziona con CI/CD, adatto a deploy continuo
• Contro: nessun branch develop per testing, richiede che main sia sempre stabile

Verdetto per team piccoli: ottima scelta. Semplice, efficace, usato da team di ogni dimensione.

3. Trunk-Based Development: la scelta moderna

Trunk-Based Development (TBD) porta GitHub Flow all'estremo: tutti lavorano direttamente su main (trunk) o con branch brevissimi (ore, non giorni).

Branch:
└── main (trunk) → tutti integrano qui frequentemente

Feature branch (opzionali):
└── durata massima: 1-2 giorni

Come funziona

1. Pull da main ogni mattina (o più spesso)
2. Sviluppi in piccoli incrementi
3. Commit e push frequenti (più volte al giorno)
4. Feature flag per codice non pronto
5. Deploy continuo da main

# Mattina: sync con main
git checkout main
git pull --rebase origin main

# Sviluppo piccolo incremento
git add .
git commit -m "feat: add login button UI"
git push origin main

# Oppure con feature branch (max 1 giorno)
git checkout -b quick-fix-header
# ... lavoro ...
git push origin quick-fix-header
# PR immediata, merge stesso giorno

Pro e contro

• Pro: integrazione continua vera, meno merge conflict, feedback rapido
• Contro: richiede disciplina, buona test coverage, feature flags

Verdetto per team piccoli: ideale se avete CI/CD maturo e cultura di test. Nel 2025 è considerata la best practice.

Quale scegliere: confronto pratico

*TBD richiede più disciplina, non più branch.

La mia raccomandazione per team piccoli

1. Team 2-3 persone senza CI/CD: GitHub Flow semplificato
2. Team 3-5 persone con CI/CD: GitHub Flow o TBD
3. Team con release versionate: GitFlow semplificato (solo main + develop + feature)

Best practice per qualsiasi workflow

Naming convention chiare

# Feature
feature/login-social
feature/JIRA-123-payment-gateway

# Bugfix
fix/header-overflow
fix/JIRA-456-login-error

# Hotfix (produzione)
hotfix/security-patch-auth

# Refactoring
refactor/user-service-cleanup

Commit message strutturati

# Formato: tipo(scope): descrizione
feat(auth): add Google OAuth login
fix(api): handle null user in response
docs(readme): update installation steps
refactor(utils): simplify date formatting
test(user): add unit tests for registration

Pull Request efficaci

• Titolo chiaro che spiega cosa, non come
• Descrizione con contesto e screenshot se UI
• Link a issue/ticket se esiste
• Checklist di auto-review
• Dimensione gestibile: max 400 righe modificate

Protezione branch

# Su GitHub/GitLab, configura:
- Require pull request reviews (almeno 1)
- Require status checks (CI passa)
- No force push su main
- No delete main

Setup pratico per team piccoli

1. Configurazione locale

# Alias utili
git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.unstage 'reset HEAD --'
git config --global alias.last 'log -1 HEAD'

# Pull con rebase di default
git config --global pull.rebase true

# Push solo branch corrente
git config --global push.default current

2. Template per PR

# .github/pull_request_template.md

## Cosa fa questa PR?


## Tipo di modifica
- [ ] Bug fix
- [ ] Nuova feature
- [ ] Refactoring
- [ ] Documentazione

## Checklist
- [ ] Ho testato le modifiche localmente
- [ ] Ho aggiornato la documentazione se necessario
- [ ] I test passano

3. CI minima

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm test
      - run: npm run lint

Errori comuni da evitare

• Branch zombie: branch aperti da settimane. Regola: se non lo tocchi da 7 giorni, chiudilo o integralo.
• Mega-merge: 50 file modificati in una PR. Dividi in incrementi più piccoli.
• Push su main senza test: anche in team piccoli, un workflow base previene disastri.
• Ignorare i conflict: risolvi subito, non "dopo". Più aspetti, peggio è.
• Non comunicare: se stai modificando file critici, avvisa il team prima.

Conclusione

Per un team piccolo nel 2025, la scelta migliore è quasi sempre GitHub Flow o Trunk-Based Development. GitFlow ha senso solo se hai requisiti specifici di versioning. I punti chiave:

• Scegli il workflow più semplice che soddisfa le tue esigenze
• Documenta le regole e assicurati che tutti le seguano
• Branch brevi, PR piccole, integrazione frequente
• Proteggi main con review e CI obbligatoria
• Usa naming convention e commit message chiari

Il workflow perfetto non esiste—esiste quello che il tuo team segue davvero. Inizia semplice, aggiungi complessità solo quando serve.