Lezione 12 di 35

Git 12

🔀 Git & GitHub · Modulo 2 · Lezione 12

Strategie di branching 🗺️

Git Flow · GitHub Flow · Trunk-based development · Scegliere la strategia giusta per il tuo progetto

⏱️ Durata stimata: 60–75 min 📊 Livello: Intermedio (Modulo 2) 🔧 Strumenti: Nessuno — lezione concettuale 📋 Prerequisiti: Lezioni 01–11 (sai fare branch, merge, rebase)

🗺️ Sapere creare branch e fare merge non basta: serve una strategia. Senza regole condivise, ogni membro del team crea branch con nomi diversi, fa merge in momenti diversi, e il repository diventa un caos ingestibile. Una branching strategy è un accordo di squadra su come usare i branch: quanti, come nominarli, quando fare merge, chi approva. In questa lezione confronti le 3 strategie più diffuse e scegli quella giusta per il tuo contesto.

🎯 Obiettivi della lezione

Capire perché serve una strategia di branching e cosa succede senza
Conoscere le 3 strategie principali: Git Flow, GitHub Flow, Trunk-based
Confrontare pro e contro di ciascuna
Scegliere la strategia appropriata per il tuo tipo di progetto
Conoscere la strategia raccomandata per progetti scolastici

📖 1. Teoria

1.1 — Perché serve una strategia

Git ti dà la libertà totale di creare branch come vuoi. Questa libertà senza regole diventa un problema quando lavori in team:

❌ Senza strategia

Marco crea branch test, Giulia crea giulia-fix, Luca lavora direttamente su main. Nessuno sa quale branch è “quello giusto”. I merge creano conflitti a catena. Il prof non capisce chi ha fatto cosa.

✅ Con strategia

Tutti seguono la stessa regola: branch da main con nome feature/nome-funzione, merge con Pull Request dopo review, main sempre funzionante. Ognuno sa cosa fare e dove trovare il codice stabile.

Una branching strategy risponde a queste domande fondamentali:

🌿

Quanti branch?

Quali branch esistono? Chi li crea? Come si chiamano?

🔀

Quando merge?

Quando un branch viene integrato? Chi approva? Serve review?

🚀

Come si rilascia?

Come si passa dal codice al “prodotto finito”? Cosa va in produzione?

1.2 — Strategia 1: Git Flow

Git Flow è la strategia più strutturata. Definisce ruoli precisi per branch diversi ed è pensata per progetti con rilasci pianificati (versioni 1.0, 2.0, ecc.).

I branch di Git Flow

main (o master)

Contiene solo il codice rilasciato in produzione. Ogni commit su main corrisponde a una versione pubblica (tag). Non si lavora mai direttamente su main.

develop

Il branch di integrazione. Qui confluiscono tutte le feature completate. Contiene il codice della “prossima versione” in preparazione.

feature/*

Uno per ogni nuova funzionalità. Parte da develop, viene integrato in develop quando la feature è completa.

release/*

Preparazione di una nuova versione. Parte da develop, riceve solo bugfix, viene integrato in main e develop.

hotfix/*

Fix urgenti in produzione. Parte da main, viene integrato sia in main (per il fix immediato) che in develop (per non perderlo nella prossima versione).

Flusso di Git Flow (semplificato)

    feature/login ──→ develop

    feature/cart  ──→ develop

                           develop ──→ release/1.0 ──→ main (tag v1.0)

                                                        hotfix/bug ──→ main + develop

✅ Pro

Ruoli chiarissimi per ogni branch. Ideale per software con versioni numerateate (app mobile, librerie). Separazione netta tra “in sviluppo” e “in produzione”. Hotfix immediati senza toccare le feature in corso.

❌ Contro

Complesso: 5 tipi di branch con regole diverse. Il branch develop aggiunge un livello di indirezione. Troppo pesante per progetti piccoli o per chi rilascia frequentemente. Il grafo diventa intricato.

1.3 — Strategia 2: GitHub Flow ⭐

GitHub Flow è radicalmente più semplice: un solo branch principale (main) e branch di feature. Niente develop, niente release, niente hotfix separati. È la strategia usata da GitHub stesso e dalla maggior parte dei progetti open source.

Le 6 regole di GitHub Flow

Main è sempre deployabile. Il codice su main funziona e può andare in produzione in qualsiasi momento.

Per lavorare su qualcosa, crea un branch da main. Il nome descrive cosa stai facendo (feature/login, fix/calcolo-iva).

Fai commit regolarmente e fai push. Il tuo lavoro è visibile su GitHub — i compagni possono vedere i progressi.

Quando sei pronto, apri una Pull Request. Descrivi cosa hai fatto e chiedi una review ai compagni o al prof.

Dopo l’approvazione, fai merge in main. Il merge avviene tramite la Pull Request su GitHub.

Dopo il merge, cancella il branch. Main è aggiornato, il branch ha servito il suo scopo.

Flusso di GitHub Flow

    main ──────────────────────────────────→

      ↘ feature/login ──(PR)──→ merge ↗

          ↘ fix/typo ──(PR)──→ merge ↗

              ↘ feature/cart ──(PR)──→ merge ↗

Semplice: branch da main → lavora → PR → review → merge → cancella branch.

✅ Pro

Semplicissimo: solo 2 tipi di branch (main + feature). Funziona per qualsiasi dimensione di team. Le Pull Request integrano naturalmente code review e discussione. Perfetto per deploy continuo e progetti web.

❌ Contro

Non gestisce nativamente versioni multiple (es. v1.0 supportata mentre sviluppi v2.0). Main deve essere sempre deployabile — serve disciplina. Per software con rilasci formali (app mobile), può servire qualcosa in più.

1.4 — Strategia 3: Trunk-based development

La più estrema: tutti lavorano su un unico branch (il “trunk”, di solito main). I feature branch, se esistono, durano pochissimo — ore, non giorni. L’idea è che integrare spesso e in piccoli pezzi riduca i conflitti e acceleri il ciclo di sviluppo.

I principi del trunk-based development

Un solo branch principale

Tutti committano su main (o branch che durano massimo 1-2 giorni).

Commit piccoli e frequenti

Niente branch che vivono per settimane. Integrazione continua, molte volte al giorno.

Feature flags

Le feature incomplete vengono nascoste con “interruttori” nel codice, non con branch separati.

✅ Pro

Zero conflitti di merge lunghi (integri subito, in piccoli pezzi). CI/CD naturale: main è sempre l’ultima versione. Velocità di rilascio massima. Usato da Google, Facebook, Netflix.

❌ Contro

Richiede test automatici robusti (se committi su main, il codice DEVE funzionare). Feature flags aggiungono complessità nel codice. Non adatto a team inesperti o senza CI/CD. Difficile per progetti scolastici senza infrastruttura di test.

1.5 — Confronto diretto delle 3 strategie

	Git Flow	GitHub Flow ⭐	Trunk-based
Complessità	Alta (5 tipi di branch)	Bassa (2 tipi)	Minima (1-2 tipi)
Branch principali	main + develop	solo main	solo main
Vita dei feature branch	Giorni/settimane	Giorni	Ore (o nessuno)
Rilasci	Pianificati (versioni)	Continui (ogni merge)	Continui (ogni commit)
Pull Request	Opzionali	Centrali	Opzionali
Richiede CI/CD	Consigliato	Consigliato	Obbligatorio
Ideale per	App con versioni, team grandi strutturati	Progetti web, team piccoli-medi, scuola	Aziende con CI/CD maturo

1.6 — La raccomandazione per la scuola: GitHub Flow

Per i progetti scolastici: usa GitHub Flow.

È la scelta giusta per il 90% dei casi scolastici perché è semplice da imparare, da insegnare e da usare. Si integra naturalmente con le Pull Request di GitHub (che imparerai nel Modulo 3) e con GitHub Classroom (Modulo 7). Non richiede infrastrutture complesse e funziona sia per i compiti individuali che per i progetti di gruppo.

GitHub Flow per un progetto scolastico di gruppo — workflow concreto

Marco

Crea feature/pagina-home da main → lavora → push → apre una Pull Request → Giulia revisiona → merge in main → cancella branch.

Giulia

Crea feature/contatti da main → lavora → push → apre una PR → Marco revisiona → merge in main → cancella branch.

Luca

Trova un bug sulla home → crea fix/typo-header da main → corregge → push → PR → merge rapido → cancella branch.

Main è sempre funzionante. Ogni contributo passa per una Pull Request. Ogni Pull Request riceve almeno una review. La storia è pulita e leggibile.

1.7 — Quando scegliere quale strategia

Il tuo progetto è…	Usa	Perché
Un compito scolastico individuale	GitHub Flow (semplificato)	Branch per feature/esercizio, merge in main. Basta così.
Un progetto di gruppo a scuola	GitHub Flow	Branch + PR + review. Ogni contributo è tracciato e revisionato.
Un sito web o una web app	GitHub Flow	Deploy continuo, niente versioni numerate. Semplicità.
Un’app mobile con versioni (v1.0, v2.0…)	Git Flow	Serve gestire release branch e supporto per versioni vecchie.
Una libreria open source con rilasci formali	Git Flow	Serve separare develop (prossima versione) da main (ultima stabile).
Un’azienda con CI/CD maturo e test automatici	Trunk-based	Massima velocità, minimo overhead di branch. Richiede disciplina e CI/CD.

💻 2. Esempi guidati

Questa lezione è concettuale — non ci sono comandi nuovi da imparare. Gli esempi mostrano come applicare GitHub Flow a scenari concreti.

Esempio A — GitHub Flow per un compito individuale

  # Il prof assegna 3 esercizi. Workflow con GitHub Flow:

  # === ESERCIZIO 1 ===

  $ git switch -c compito/esercizio-1

  # …lavori sull’esercizio, fai commit…

  $ git switch main && git merge compito/esercizio-1

  $ git branch -d compito/esercizio-1

# === ESERCIZIO 2 ===

$ git switch -c compito/esercizio-2

# …lavori, commit…

$ git switch main && git merge compito/esercizio-2

$ git branch -d compito/esercizio-2

# === ESERCIZIO 3 ===

# …stesso pattern…

$ git log –oneline –graph

# Storia pulita: ogni esercizio è un gruppo di commit separato.

Esempio B — GitHub Flow per un progetto di gruppo

Scenario: progetto sito web della classe (3 studenti)

Giorno 1

Il team crea il repository su GitHub con README.md e la struttura base. Tutti clonano. Si dividono il lavoro: Marco → header/navbar, Giulia → pagina about, Luca → footer.

Giorno 2-3

Ciascuno lavora sul proprio branch (feature/header, feature/about, feature/footer). Fanno commit e push regolarmente.

Giorno 4

Marco finisce per primo → apre una PR → Giulia revisiona → merge in main. Giulia aggiorna il suo branch (git pull origin main o rebase), finisce → PR → Luca revisiona → merge. Stessa cosa per Luca.

Giorno 5

Main ha il sito completo. Il prof può vedere ogni PR, ogni commit, ogni review. La storia mostra chi ha fatto cosa.

Esempio C — Quando Git Flow servirebbe (e perché non ora)

Scenario: un’app Android con versioni sul Play Store

L’app è alla versione 2.3 sul Play Store. Il team sta sviluppando la 3.0 con nuove funzionalità. Nel frattempo, un utente segnala un bug critico nella 2.3 che va corretto subito. Con GitHub Flow semplice, non c’è un modo pulito di fare il fix sulla 2.3 senza includere le feature incomplete della 3.0. Con Git Flow, il fix parte da main (che contiene la 2.3 rilasciata), viene integrato sia in main (fix immediato) che in develop (per la 3.0). Questo scenario richiede la complessità di Git Flow — ma per un progetto scolastico, GitHub Flow basta e avanza.

🏋️ 3. Esercizi

🟢 Esercizio 1 — Identifica la strategia (Facile)

Per ciascuno di questi grafi di git log --graph, identifica quale strategia di branching è stata usata:

    Grafo A:

    * commit 6

    * commit 5

    * commit 4

    * commit 3

    * commit 2

    * commit 1

    → Strategia: ???

“`
Grafo B:

*   Merge PR #3

|\

| * Add footer

|/

*   Merge PR #2

|\

| * Fix typo

|/

*   Merge PR #1

|\

| * Add header

|/

* Initial commit

→ Strategia: ???

Grafo C: (contiene branch “develop”, “release/1.0”, “hotfix/bug”)

→ Strategia: ???
“`

🔵 Esercizio 2 — Simula GitHub Flow (Medio)

a) Crea un repository progetto-github-flow con commit iniziale.
b) Simula 3 feature seguendo GitHub Flow rigoroso:
— feature/header: 2 commit → merge in main → cancella branch
— feature/gallery: 3 commit → merge in main (con –no-ff) → cancella branch
— fix/typo-readme: 1 commit → merge in main → cancella branch
c) Verifica con git log --oneline --graph che la storia sia leggibile.
d) Quanti branch attivi ci sono alla fine? (Solo main.)

🟠 Esercizio 3 — Scegli la strategia (Medio)

Per ciascuno di questi scenari, indica quale strategia di branching consiglieresti e spiega il perché in 2-3 righe:

a) Un blog personale aggiornato una volta alla settimana.
b) Un videogioco mobile con versioni trimestrali e patch di emergenza tra una versione e l’altra.
c) Un progetto di 4 studenti per l’esame di informatica, con consegna tra 2 mesi.
d) Un’azienda SaaS con 50 sviluppatori che rilascia più volte al giorno.
e) Una libreria Python open source usata da migliaia di progetti, con versioni 1.x e 2.x supportate contemporaneamente.

🟣 Esercizio 4 — Scrivi le regole per il tuo team (Difficile)

Immagina di essere il team leader di un gruppo di 4 studenti. Scrivi un documento “Regole di branching” (max 1 pagina) che include:

a) Quale strategia adottate (e perché).
b) Come si chiamano i branch (convenzioni di naming).
c) Da dove partono i branch e dove vengono integrati.
d) Chi approva le Pull Request (quante approvazioni servono).
e) Quando si cancellano i branch.
f) Cosa fare se main è rotto (procedura di emergenza).
g) Crea il file CONTRIBUTING.md nel tuo repository con queste regole.

❓ 4. Quiz di verifica

1. Qual è la differenza principale tra Git Flow e GitHub Flow?

Mostra risposta

Git Flow ha 5 tipi di branch con ruoli distinti (main, develop, feature, release, hotfix) ed è pensato per progetti con rilasci pianificati e versioni numerate. GitHub Flow ha solo 2 tipi (main + feature branch) ed è pensato per rilasci continui — ogni merge in main è potenzialmente un rilascio. Git Flow separa il codice “in sviluppo” (develop) da quello “in produzione” (main). In GitHub Flow, main è sia il branch di sviluppo che quello di produzione — le feature entrano tramite Pull Request.

2. Perché GitHub Flow è raccomandato per i progetti scolastici?

Mostra risposta

Perché è semplice da imparare e da usare: solo due tipi di branch, regole chiare (branch da main, PR, review, merge, cancella). Non richiede infrastrutture complesse (CI/CD, test automatici) e si integra naturalmente con GitHub (Pull Request, code review). Per un progetto scolastico non servono rilasci formali con versioni numerate — GitHub Flow dà la struttura giusta senza l’overhead di Git Flow. I progetti scolastici raramente necessitano di supportare più versioni in parallelo o di gestire hotfix su codice in produzione.

3. Cos’è il trunk-based development e perché non è adatto ai principianti?

Mostra risposta

Il trunk-based development prevede che tutti committino su un unico branch (main), con branch di feature che durano al massimo poche ore. Le feature incomplete vengono nascoste con “feature flags” nel codice. Non è adatto ai principianti perché richiede test automatici robusti (ogni commit su main deve funzionare), CI/CD maturo, e la capacità di scrivere feature flags — tutte competenze avanzate. Senza queste basi, committare direttamente su main significa rompere il progetto regolarmente. È la strategia usata da aziende come Google e Facebook che hanno infrastrutture di test enormi.

4. In GitHub Flow, cosa deve essere vero di main in ogni momento?

Mostra risposta

Main deve essere sempre deployabile — il codice su main deve funzionare in ogni momento. Questo significa che non si committano mai modifiche incomplete o rotte direttamente su main. Tutto il lavoro avviene su feature branch, viene testato e revisionato tramite Pull Request, e solo dopo l’approvazione viene integrato in main. Se main si rompe (succede, anche con le PR), la priorità è ripristinarlo — con un fix urgente o con un revert del merge problematico.

5. A cosa serve il branch “develop” in Git Flow?

Mostra risposta

Il branch develop è il punto di integrazione per tutte le feature in sviluppo. I feature branch partono da develop e vengono integrati in develop quando sono completi. Il codice su develop rappresenta la “prossima versione” in preparazione — potrebbe non essere ancora stabile. Quando develop è pronto per un rilascio, si crea un release branch da develop, si fanno gli ultimi ritocchi, e poi il release branch viene integrato in main (che diventa la nuova versione rilasciata) e di nuovo in develop (per non perdere i bugfix). In GitHub Flow, develop non esiste — le feature vanno direttamente in main.

6. Cosa succede se un team non adotta nessuna strategia di branching?

Mostra risposta

Il caos. Ogni membro del team crea branch con nomi arbitrari, lavora direttamente su main, fa merge in momenti casuali. Nessuno sa quale sia la versione “buona” del progetto, i conflitti si moltiplicano perché non c’è coordinamento su chi tocca cosa, e la storia del repository diventa illeggibile. In un progetto scolastico, il prof non riesce a capire chi ha fatto cosa e quando. La branching strategy non è burocrazia — è un accordo di squadra che permette a tutti di lavorare in parallelo senza calpestarsi i piedi.

📚 Riepilogo della lezione

Cosa hai imparato oggi:

Una branching strategy è un accordo di squadra su come usare i branch
Git Flow: 5 tipi di branch (main, develop, feature, release, hotfix). Per rilasci pianificati con versioni. Complesso.
GitHub Flow ⭐: solo main + feature branch. Branch → PR → review → merge. Semplice e universale.
Trunk-based: tutti su main, branch brevissimi, feature flags. Per aziende con CI/CD maturo.
Per la scuola: GitHub Flow — semplice, si integra con le PR, traccia chi fa cosa
La strategia risponde a: quanti branch? quando merge? come si rilascia?
Senza strategia = caos. Con strategia = lavoro parallelo ordinato.

🎉 Congratulazioni! Hai completato il Modulo 2 — Branching e Merging. Sai creare branch, fare merge (fast-forward e three-way), risolvere conflitti, fare rebase e scegliere la strategia giusta per il tuo progetto. Dal prossimo modulo porti il tuo lavoro online con GitHub — repository remoti, push, pull, Pull Request e collaborazione.

Prossima lezione →

Lezione 13 — Account GitHub e autenticazione
Creare l’account GitHub. SSH key vs token HTTPS.
Configurazione sicura. GitHub Student Developer Pack.

Corso Git & GitHub · Per studenti e insegnanti · Lezione 12 di 45